[JBoss JIRA] (WFLY-13376) Cannot change jgroups subsystem attribute without reload
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13376?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved JBEAP-19225 to WFLY-13376:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13376 (was: JBEAP-19225)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 19.0.0.Final
(was: 7.4.0.CD19)
> Cannot change jgroups subsystem attribute without reload
> --------------------------------------------------------
>
> Key: WFLY-13376
> URL: https://issues.redhat.com/browse/WFLY-13376
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 19.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> We hit a change in behaviour while testing 7.4.0.CD19.
> In 7.3.0.GA and before it was perfectly fine changing jgroups attribute without reloading:
> {code:java}
> /subsystem=jgroups/channel=ee:write-attribute(name=cluster, value=anything){allow-resource-service-restart=true}
> {"outcome" => "success"}
> {code}
> Now with 7.4.0.CD19-CR1 it is no longer possible:
> {code:java}
> /subsystem=jgroups/channel=ee:write-attribute(name=cluster, value=anything){allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException:
> Service org.wildfly.clustering.jgroups.channel.ee.captor is already registered",
> "rolled-back" => true
> }
> {code}
> Server log exception:
> {code:java}
> 18:20:19,676 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.jgroups.channel.ee.captor is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.set(ServiceRegistrationImpl.java:135)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:243)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:747)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:260)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2065)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:260)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2065)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:192)
> at org.jboss.as.controller.OperationContextImpl.installService(OperationContextImpl.java:2041)
> at org.jboss.as.controller.OperationContextImpl.access$600(OperationContextImpl.java:134)
> at org.jboss.as.controller.OperationContextImpl$2$1.installService(OperationContextImpl.java:763)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2182)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceHandler.installServices(ChannelServiceHandler.java:87)
> at org.jboss.as.clustering.controller.WriteAttributeStepHandler.restartServices(WriteAttributeStepHandler.java:121)
> at org.jboss.as.clustering.controller.WriteAttributeStepHandler.applyUpdateToRuntime(WriteAttributeStepHandler.java:103)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1413)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:429)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:246)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:246)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:138)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:162)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:158)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
> I was able to locate the change to WFLY-12601 (https://github.com/wildfly/wildfly/commit/6fff03502b457985ded696985daf455...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5236) Decision table validation produces runtime exception in Business Central
by Tracy Hires (Jira)
Tracy Hires created DROOLS-5236:
-----------------------------------
Summary: Decision table validation produces runtime exception in Business Central
Key: DROOLS-5236
URL: https://issues.redhat.com/browse/DROOLS-5236
Project: Drools
Issue Type: Bug
Components: decision tables, DMN Editor
Affects Versions: 7.34.0.Final
Reporter: Tracy Hires
Assignee: Mario Fusco
Attachments: Benefits Calculator.dmn
In Business Central's DMN Modeler, a decision table with "Unique" Hit policy and overlapping rules, when placed into a context, produces a Runtime Exception on validate. Error Message is: "[uuid] DMN: Validation of the DMN Model cannot be performed because of some runtime exception 'org.kie.dmn.model.v1_2.TContextEntry cannot be cast to org.kie.dmn.model.api.NamedElement'. (DMN Validation stopped on failed validation for some DMN Model)"
We expected to see 'DMN: Overlap detected: Overlap values: [...] for rules: [...]. UNIQUE hit policy decision tables can only have one matching rule' among the validation errors, and in fact this error is displayed when the decision table is not nested within a context.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4922) The embedded host and server handlers hang on start
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFCORE-4922?page=com.atlassian.jira.plug... ]
Yeray Borges Santana updated WFCORE-4922:
-----------------------------------------
Component/s: Embedded
> The embedded host and server handlers hang on start
> ---------------------------------------------------
>
> Key: WFCORE-4922
> URL: https://issues.redhat.com/browse/WFCORE-4922
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Affects Versions: 12.0.0.Beta1
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
>
> Recently we changed the way the {{EmbedHostControllerHandler}} and {{EmbedServerHandler}} wait for the embedded host/server until it starts.
> We were using a pooling executing management operations to check the process state. We needed a different solution to be able to check the process state when the embedded host/server was launched with and empty configuration file.
> In the new approach we exposed the process state to the client so it can be directly pooling without requiring a management operation.
> Currently the update of this internal field is racy, and a hang can occurs starting the embedded.
> We saw this bug in the CI test suite: https://ci.wildfly.org/viewLog.html?buildId=197876&buildTypeId=WF_MasterW...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4922) The embedded host and server handlers hang on start
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFCORE-4922:
--------------------------------------------
Summary: The embedded host and server handlers hang on start
Key: WFCORE-4922
URL: https://issues.redhat.com/browse/WFCORE-4922
Project: WildFly Core
Issue Type: Bug
Affects Versions: 12.0.0.Beta1
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Recently we changed the way the {{EmbedHostControllerHandler}} and {{EmbedServerHandler}} wait for the embedded host/server until it starts.
We were using a pooling executing management operations to check the process state. We needed a different solution to be able to check the process state when the embedded host/server was launched with and empty configuration file.
In the new approach we exposed the process state to the client so it can be directly pooling without requiring a management operation.
Currently the update of this internal field is racy, and a hang can occurs starting the embedded.
We saw this bug in the CI test suite: https://ci.wildfly.org/viewLog.html?buildId=197876&buildTypeId=WF_MasterW...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years