[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-1752:
-----------------------------------------
Summary: The deployment-overlay command fails to redeploy affected deployments
Key: WFCORE-1752
URL: https://issues.jboss.org/browse/WFCORE-1752
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.0.Alpha5
Reporter: ehsavoie Hugonnet
Assignee: Alexey Loubyansky
The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7024) show-resources operation of jaxrs subsystem must provide more informations and statistics about end-point
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-7024?page=com.atlassian.jira.plugin.... ]
Lin Gao moved JBEAP-5814 to WFLY-7024:
--------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7024 (was: JBEAP-5814)
Issue Type: Feature Request (was: Enhancement)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: REST
(was: REST)
> show-resources operation of jaxrs subsystem must provide more informations and statistics about end-point
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7024
> URL: https://issues.jboss.org/browse/WFLY-7024
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided.
> Example:
> {code:java}
> @GET
> @Path("entity/get")
> @Produces(MediaType.APPLICATION_JSON)
> public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) {
> Person per = new Person();
> per.setName("per");
> per.setFamily("son");
> return per;
> }
> {code}
> Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}:
> {noformat}
> {
> "resource-class" => "org.resteasy.simple.deployment.AdvancedService",
> "resource-path" => "/sample/entity/get",
> "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"]
> },
> {noformat}
> There should be information about "boolean v" parameter and about returned type (Person).
> ---
> jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)
> Some statistics could be be activated and printed, only if end-point is also EJB bean, example:
> {noformat}
> /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> /deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1256) ForceEagerActivationOption and "not()" LHS pattern does not invoke matchCreated listener
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1256?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1256:
----------------------------------------
Typical steps of creation and usage of the session with the listener is as follows:
# create the KieSession
# register the listener
# fireAllRules() - or fireUntilHalt()
the same is also outlined in the reported test.
However with the rules as described here, and the option {{ForceEagerActivationOption.YES}} enabled, the matchCreated events are happening contextually to step 1, hence _before_ the listener gets to be actually registered.
> ForceEagerActivationOption and "not()" LHS pattern does not invoke matchCreated listener
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1256
> URL: https://issues.jboss.org/browse/DROOLS-1256
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta1
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> Given the following rules
> {code:java}
> rule ND
> when
> not ( Double() )
> then
> // do nothing.
> end
> rule ND2
> salience 1
> when
> not ( Double() )
> then
> insert( new Double(0) );
> end
> {code}
> and KieSession created with {{ForceEagerActivationOption.YES}} and a generic AgendaEventListener on fire all rules returns:
> {code:java}
> created: 0 cancelled: 1 fired: 1
> {code}
> hence incoherent as matchcreated .
> Expected: created=2, cancelled=1, fired=1.
> Reporting this as also I understand this eager option is used by jBPM.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from ON_QA to VERIFIED
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
> Fix For: 2.0.3.Final
>
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1221) Add fail-safe and scalability functionality to the Drools (CEP) rules engine
by Tom Pijl (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1221?page=com.atlassian.jira.plugi... ]
Tom Pijl commented on DROOLS-1221:
----------------------------------
Hi Youcef,
Thanks for the slide set about the Italian HACEP project. It makes it much more clear.
I intend to port the Italian HACEP solution to the Amazon cloud replacing Infinispan, ActiveMQ, Camel Route, etc. with Amazon equivalents. The grouping is done on Tenant (aka customer environment).
The domain is Business Event Monitoring in the cloud.
Are you going to use Apache Geode in your project as a replacement for Infinispan? If so, why?
> Add fail-safe and scalability functionality to the Drools (CEP) rules engine
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1221
> URL: https://issues.jboss.org/browse/DROOLS-1221
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: Drools (CEP) Rule engine 6.4.0.Final
> Reporter: Tom Pijl
> Assignee: Mario Fusco
>
> The Drools Rule engine is currently not fail-safe and scalable which is a requirement for Cloud deployment.
> Add a possibility to persist the state of the working memory after each state change (perhaps linked to the fireAllRules()?) and related to that the possibility to restore the state in case of a crash (fail-safe requirement).
> This persistent state store can also be used to synchronize multiple engine instances (scalability requirement).
> Of course this has major impact on the performance of the engine, but it is the only way to make the engine useful in a multi-tenant Cloud environment
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1750) [2.2.x] WFLYCTL0357 warning upon undeploying any deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1750?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1750:
----------------------------------------
Assignee: Frank Langelage (was: Chao Wang)
Resolution: Done
> [2.2.x] WFLYCTL0357 warning upon undeploying any deployment
> -----------------------------------------------------------
>
> Key: WFCORE-1750
> URL: https://issues.jboss.org/browse/WFCORE-1750
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.2.0.Final
> Reporter: Frank Langelage
> Assignee: Frank Langelage
> Fix For: 2.2.1.Final
>
>
> EAP produces following warning upon undeployment:
> {code}WARN [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address []{code}
> The warning is produced for both managed and unmanaged deployments.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months