[JBoss JIRA] (WFCORE-2993) NPE after pressing tab in CLI when adding connector in remoting subsystem
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2993?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise moved JBEAP-11737 to WFCORE-2993:
------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2993 (was: JBEAP-11737)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Domain Management
(was: CLI)
(was: Remoting)
Affects Version/s: (was: 7.1.0.ER1)
Affects Testing: (was: Regression)
> NPE after pressing tab in CLI when adding connector in remoting subsystem
> -------------------------------------------------------------------------
>
> Key: WFCORE-2993
> URL: https://issues.jboss.org/browse/WFCORE-2993
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Critical
>
> NPE [1] pops up in server log when user wants to use auto complete in remoting subsystem in CLI. This is a regression against 7.0.0.GA.
> [1]
> {code}
> [Host Controller] 13:11:22,697 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("suggest-capabilities") failed - address: ([
> [Host Controller] ("host" => "master"),
> [Host Controller] ("core-service" => "capability-registry")
> [Host Controller] ]): java.lang.NullPointerException
> [Host Controller] at org.jboss.as.controller.capability.registry.IncludingResourceCapabilityScope.getIncludingScopes(IncludingResourceCapabilityScope.java:65)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.findSatisfactoryCapability(CapabilityRegistry.java:902)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.hasCapability(CapabilityRegistry.java:577)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.lambda$getDynamicCapabilityNames$7(CapabilityRegistry.java:942)
> [Host Controller] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> [Host Controller] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> [Host Controller] at java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)
> [Host Controller] at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> [Host Controller] at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> [Host Controller] at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [Host Controller] at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [Host Controller] at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.getDynamicCapabilityNames(CapabilityRegistry.java:951)
> [Host Controller] at org.jboss.as.server.controller.resources.CapabilityRegistryResourceDefinition.lambda$registerOperations$4(CapabilityRegistryResourceDefinition.java:182)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:978)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:724)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:448)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> [Host Controller] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> [Host Controller] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] at java.lang.Thread.run(Thread.java:748)
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Host Controller]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2992) Can't restart domain master host with slave attached
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2992?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2992:
------------------------------------------
Can you take a thread dump of the WildFly processes when this happens? Even just a killall -3 java and attaching a paste of the console log output from the HCs would help. The server output will be intermixed with the HC output but that's ok.
> Can't restart domain master host with slave attached
> ----------------------------------------------------
>
> Key: WFCORE-2992
> URL: https://issues.jboss.org/browse/WFCORE-2992
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta11
> Reporter: Matthew Casperson
> Assignee: Brian Stansberry
>
> With a domain controller started on a host called master and no slaves attached, I can restart the host master with the command
> *./jboss-cli.ps1 -c --command="/host=master:shutdown(restart=true)"*
> over and over with no issues.
> Once a domain slave is attached, I often will not be able to restart the host master with the same command. It will shutdown, but not restart. The host master does seem to occasionally restart as expected, but not always.
> The output from the domain controller is this:
> {code:java}
> Registered remote slave host "desktop-p010d77", JBoss WildFly Full 11.0.0.Alpha1 (WildFly 3.0.0.Beta11)
> [Host Controller] 14:14:19,294 INFO [org.jboss.as.host.controller] (management-handler-thread - 1) WFLYHC0180: Shutting
> down in response to management operation 'shutdown'
> 14:14:19,300 INFO [org.jboss.as.process] (Thread-15) WFLYPC0017: Shutting down process controller
> 14:14:19,301 INFO [org.jboss.as.process.Host Controller.status] (Thread-15) WFLYPC0019: Stopping process 'Host Controll
> er'
> [Host Controller] 14:14:19,317 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-one
> [Host Controller] 14:14:19,320 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-two
> 14:14:19,320 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-one'
> 14:14:19,321 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-two'
> [Server:server-one] 14:14:19,322 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-two] 14:14:19,324 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-one] 14:14:19,343 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,351 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-5) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,354 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-one] 14:14:19,357 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,362 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,358 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-one] 14:14:19,360 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8443
> [Server:server-two] 14:14:19,367 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-3) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,364 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 67) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> [Server:server-two] 14:14:19,370 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-two] 14:14:19,372 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8593
> [Server:server-two] 14:14:19,374 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 35) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> [Server:server-one] 14:14:19,392 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-two] 14:14:19,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-two] 14:14:19,414 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-one] 14:14:19,426 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 74) AMQ151003: res
> ource adaptor stopped
> [Server:server-two] 14:14:19,437 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 73) AMQ151003: res
> ource adaptor stopped
> [Server:server-one] 14:14:19,475 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3d9fbbfb-5620-11e7-9672-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-one] 14:14:19,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-one] 14:14:19,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8080
> [Server:server-one] 14:14:19,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,488 INFO [org.jboss.as.host.controller] (management task-3) WFLYHC0027: Unregistering server
> server-one
> [Server:server-two] 14:14:19,491 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 73) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3da40166-5620-11e7-9b85-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-two] 14:14:19,493 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-two] 14:14:19,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8230
> [Server:server-two] 14:14:19,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,507 INFO [org.jboss.as.host.controller] (management task-5) WFLYHC0027: Unregistering server
> server-two
> [Server:server-one] 14:14:19,510 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 174ms
> [Server:server-two] 14:14:19,518 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 159ms
> 14:14:19,883 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'S
> erver:server-one' finished with an exit status of 0
> [Host Controller] 14:14:19,884 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-one
> 14:14:19,903 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'S
> erver:server-two' finished with an exit status of 0
> [Host Controller] 14:14:19,904 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-two
> [Host Controller] 14:14:19,906 WARN [org.jboss.as.domain.controller] (MSC service thread 1-1) WFLYHC0030: Connection to
> remote host "desktop-p010d77" closed unexpectedly
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
On wildfly 10.1.0.0.Final with eclipselink, the problem persists.
{panel}
2017-06-21 18:39:47,993 INFO [wildfly.bug.onsuccess.facade.ModifyEntityAndFireEventFacade] (default task-35) We will now modify the entity: db.model.SomeEntity@4e2224a0 we will toogle the text to either true or false
2017-06-21 18:39:48,005 INFO [wildfly.bug.onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade] (default task-35) START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent
2017-06-21 18:39:48,008 INFO [wildfly.bug.onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade] (default task-35) Before Refresh value was: false, After Refresh: true. Value on entity passed by event object as new value was: true
2017-06-21 18:39:48,009 ERROR [wildfly.bug.onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade] (default task-35) Wildfly ON_SUCCESS handling observing stale entity that does not match what transaction persisted. EntityMode before refresh: false And After Refresh: true For Equipment: 1
<---------------------- NOTE: here the code is detecting that entity is stale.
2017-06-21 18:39:48,009 INFO [wildfly.bug.onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade] (default task-35) ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent
{panel}
I will see what is the outcome when using hibernate.
The domain model should in this case be trivial enough to not have any problems switching the persistence provider.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2992) Can't restart domain master host with slave attached
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2992?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2992:
----------------------------------------
Component/s: Domain Management
Assignee: Brian Stansberry (was: Jason Greene)
> Can't restart domain master host with slave attached
> ----------------------------------------------------
>
> Key: WFCORE-2992
> URL: https://issues.jboss.org/browse/WFCORE-2992
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta11
> Reporter: Matthew Casperson
> Assignee: Brian Stansberry
>
> With a domain controller started on a host called master and no slaves attached, I can restart the host master with the command
> *./jboss-cli.ps1 -c --command="/host=master:shutdown(restart=true)"*
> over and over with no issues.
> Once a domain slave is attached, I often will not be able to restart the host master with the same command. It will shutdown, but not restart. The host master does seem to occasionally restart as expected, but not always.
> The output from the domain controller is this:
> {code:java}
> Registered remote slave host "desktop-p010d77", JBoss WildFly Full 11.0.0.Alpha1 (WildFly 3.0.0.Beta11)
> [Host Controller] 14:14:19,294 INFO [org.jboss.as.host.controller] (management-handler-thread - 1) WFLYHC0180: Shutting
> down in response to management operation 'shutdown'
> 14:14:19,300 INFO [org.jboss.as.process] (Thread-15) WFLYPC0017: Shutting down process controller
> 14:14:19,301 INFO [org.jboss.as.process.Host Controller.status] (Thread-15) WFLYPC0019: Stopping process 'Host Controll
> er'
> [Host Controller] 14:14:19,317 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-one
> [Host Controller] 14:14:19,320 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-two
> 14:14:19,320 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-one'
> 14:14:19,321 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-two'
> [Server:server-one] 14:14:19,322 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-two] 14:14:19,324 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-one] 14:14:19,343 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,351 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-5) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,354 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-one] 14:14:19,357 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,362 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,358 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-one] 14:14:19,360 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8443
> [Server:server-two] 14:14:19,367 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-3) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,364 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 67) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> [Server:server-two] 14:14:19,370 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-two] 14:14:19,372 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8593
> [Server:server-two] 14:14:19,374 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 35) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> [Server:server-one] 14:14:19,392 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-two] 14:14:19,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-two] 14:14:19,414 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-one] 14:14:19,426 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 74) AMQ151003: res
> ource adaptor stopped
> [Server:server-two] 14:14:19,437 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 73) AMQ151003: res
> ource adaptor stopped
> [Server:server-one] 14:14:19,475 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3d9fbbfb-5620-11e7-9672-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-one] 14:14:19,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-one] 14:14:19,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8080
> [Server:server-one] 14:14:19,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,488 INFO [org.jboss.as.host.controller] (management task-3) WFLYHC0027: Unregistering server
> server-one
> [Server:server-two] 14:14:19,491 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 73) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3da40166-5620-11e7-9b85-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-two] 14:14:19,493 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-two] 14:14:19,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8230
> [Server:server-two] 14:14:19,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,507 INFO [org.jboss.as.host.controller] (management task-5) WFLYHC0027: Unregistering server
> server-two
> [Server:server-one] 14:14:19,510 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 174ms
> [Server:server-two] 14:14:19,518 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 159ms
> 14:14:19,883 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'S
> erver:server-one' finished with an exit status of 0
> [Host Controller] 14:14:19,884 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-one
> 14:14:19,903 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'S
> erver:server-two' finished with an exit status of 0
> [Host Controller] 14:14:19,904 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-two
> [Host Controller] 14:14:19,906 WARN [org.jboss.as.domain.controller] (MSC service thread 1-1) WFLYHC0030: Connection to
> remote host "desktop-p010d77" closed unexpectedly
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2992) Can't restart domain master host with slave attached
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2992?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-8975 to WFCORE-2992:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2992 (was: WFLY-8975)
Affects Version/s: 3.0.0.Beta11
(was: 11.0.0.Alpha1)
> Can't restart domain master host with slave attached
> ----------------------------------------------------
>
> Key: WFCORE-2992
> URL: https://issues.jboss.org/browse/WFCORE-2992
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta11
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> With a domain controller started on a host called master and no slaves attached, I can restart the host master with the command
> *./jboss-cli.ps1 -c --command="/host=master:shutdown(restart=true)"*
> over and over with no issues.
> Once a domain slave is attached, I often will not be able to restart the host master with the same command. It will shutdown, but not restart. The host master does seem to occasionally restart as expected, but not always.
> The output from the domain controller is this:
> {code:java}
> Registered remote slave host "desktop-p010d77", JBoss WildFly Full 11.0.0.Alpha1 (WildFly 3.0.0.Beta11)
> [Host Controller] 14:14:19,294 INFO [org.jboss.as.host.controller] (management-handler-thread - 1) WFLYHC0180: Shutting
> down in response to management operation 'shutdown'
> 14:14:19,300 INFO [org.jboss.as.process] (Thread-15) WFLYPC0017: Shutting down process controller
> 14:14:19,301 INFO [org.jboss.as.process.Host Controller.status] (Thread-15) WFLYPC0019: Stopping process 'Host Controll
> er'
> [Host Controller] 14:14:19,317 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-one
> [Host Controller] 14:14:19,320 INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 40) WFLYHC0024: S
> topping server server-two
> 14:14:19,320 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-one'
> 14:14:19,321 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 4) WFLYPC0019: Stopping
> process 'Server:server-two'
> [Server:server-one] 14:14:19,322 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-two] 14:14:19,324 INFO [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut
> down; shutting down
> [Server:server-one] 14:14:19,343 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,351 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-5) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,354 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-one] 14:14:19,357 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,362 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0
> 010: Unbound data source [java:jboss/datasources/ExampleDS]
> [Server:server-one] 14:14:19,358 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-one] 14:14:19,360 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8443
> [Server:server-two] 14:14:19,367 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-3) WFLYMSGAMQ000
> 6: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> [Server:server-one] 14:14:19,364 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 67) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> [Server:server-two] 14:14:19,370 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0011: Unbound
> JCA ConnectionFactory [java:/JmsXA]
> [Server:server-two] 14:14:19,371 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HT
> TPS listener https suspending
> [Server:server-two] 14:14:19,372 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HT
> TPS listener https stopped, was bound to 127.0.0.1:8593
> [Server:server-two] 14:14:19,374 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 35) WFLY
> MSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> [Server:server-one] 14:14:19,392 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-two] 14:14:19,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host defaul
> t-host stopping
> [Server:server-two] 14:14:19,414 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Sto
> pped Driver service with driver-name = h2
> [Server:server-one] 14:14:19,426 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 74) AMQ151003: res
> ource adaptor stopped
> [Server:server-two] 14:14:19,437 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 73) AMQ151003: res
> ource adaptor stopped
> [Server:server-one] 14:14:19,475 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3d9fbbfb-5620-11e7-9672-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-one] 14:14:19,475 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-one] 14:14:19,476 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8080
> [Server:server-one] 14:14:19,478 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,488 INFO [org.jboss.as.host.controller] (management task-3) WFLYHC0027: Unregistering server
> server-one
> [Server:server-two] 14:14:19,491 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 73) AMQ22
> 1002: Apache ActiveMQ Artemis Message Broker version 1.5.3.jbossorg-003 [3da40166-5620-11e7-9b85-9cb6d0de7033] stopped,
> uptime 3 minutes
> [Server:server-two] 14:14:19,493 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0008: Undertow HT
> TP listener default suspending
> [Server:server-two] 14:14:19,495 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0007: Undertow HT
> TP listener default stopped, was bound to 127.0.0.1:8230
> [Server:server-two] 14:14:19,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0004: Undertow 1.
> 4.11.Final stopping
> [Host Controller] 14:14:19,507 INFO [org.jboss.as.host.controller] (management task-5) WFLYHC0027: Unregistering server
> server-two
> [Server:server-one] 14:14:19,510 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 174ms
> [Server:server-two] 14:14:19,518 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (
> WildFly Core 3.0.0.Beta11) stopped in 159ms
> 14:14:19,883 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'S
> erver:server-one' finished with an exit status of 0
> [Host Controller] 14:14:19,884 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-one
> 14:14:19,903 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'S
> erver:server-two' finished with an exit status of 0
> [Host Controller] 14:14:19,904 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027:
> Unregistering server server-two
> [Host Controller] 14:14:19,906 WARN [org.jboss.as.domain.controller] (MSC service thread 1-1) WFLYHC0030: Connection to
> remote host "desktop-p010d77" closed unexpectedly
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2197) Merge doesn't work properly
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2197?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2197:
--------------------------------
3.4.2 is also 3.5 years old... so the things I said in [1] still applies...
> Merge doesn't work properly
> ---------------------------
>
> Key: JGRP-2197
> URL: https://issues.jboss.org/browse/JGRP-2197
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Allen Zhao
> Assignee: Bela Ban
> Priority: Critical
> Attachments: MergeTest.java, jgroups.log, jgroupsConfig.xml
>
>
> Using the attached jGroups configuration file and sample code based on the Draw example, run two MergeTest instances alanz-dev-54589 and alanz-dev-53593 on one machine, and another instance , AllenMAC-4773 on the second machine; both machines are in the same network connected by a cable.
> Initially all three instances are in the same group, then unplug the cable from the second machine, two groups formed as expected:
> group1: alanz-dev-54589 and alanz-dev-53593
> group2: AllenMAC-4773
> Then plug the cable into the second machine again, the groups merged into one group with all the three members.
> These are good as expected. Keeping doing these by unplug/plug the cable into the second machine, it took around 5 times until the following happened, which is unexpected:
> when AllenMAC-4773 merged into the group composed by alanz-dev-54589 and alanz-dev-53593, it kicked alanz-dev-54589 out, and the two groups formed: MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], and alanz-dev-54589 formed a group by itself.
> Please see the sample code output from the two instances run on the first machine as follows:
> ==============alanz-dev-54589===================
> -------------------------------------------------------------------
> GMS: address=alanz-dev-54589, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63608
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|0] (1) [alanz-dev-54589]
> ** View=[alanz-dev-54589|1] (2) [alanz-dev-54589, AllenMAC-4773]
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> ================alanz-dev-53593=======================
> ---------------------------------------------------------------------
> GMS: address=alanz-dev-53593, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63610
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|13] (1) [alanz-dev-53593], [AllenMAC-4773|13] (1) [AllenMAC-4773]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> The issue happened in our system which uses jGroups for data replication. I turned on all jGroups log, and got some useful log information as the attached. It seems that at some point, a merge request from AllenMAC-4773 was received by alanz-dev-53593, and in that message, mbrs only contained alanz-dev-53593.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2197) Merge doesn't work properly
by Allen Zhao (JIRA)
[ https://issues.jboss.org/browse/JGRP-2197?page=com.atlassian.jira.plugin.... ]
Allen Zhao reopened JGRP-2197:
------------------------------
Sorry that I entered the wrong version number. The version with the issue should be 3.4.2.Final.
> Merge doesn't work properly
> ---------------------------
>
> Key: JGRP-2197
> URL: https://issues.jboss.org/browse/JGRP-2197
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Allen Zhao
> Assignee: Bela Ban
> Priority: Critical
> Attachments: MergeTest.java, jgroups.log, jgroupsConfig.xml
>
>
> Using the attached jGroups configuration file and sample code based on the Draw example, run two MergeTest instances alanz-dev-54589 and alanz-dev-53593 on one machine, and another instance , AllenMAC-4773 on the second machine; both machines are in the same network connected by a cable.
> Initially all three instances are in the same group, then unplug the cable from the second machine, two groups formed as expected:
> group1: alanz-dev-54589 and alanz-dev-53593
> group2: AllenMAC-4773
> Then plug the cable into the second machine again, the groups merged into one group with all the three members.
> These are good as expected. Keeping doing these by unplug/plug the cable into the second machine, it took around 5 times until the following happened, which is unexpected:
> when AllenMAC-4773 merged into the group composed by alanz-dev-54589 and alanz-dev-53593, it kicked alanz-dev-54589 out, and the two groups formed: MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], and alanz-dev-54589 formed a group by itself.
> Please see the sample code output from the two instances run on the first machine as follows:
> ==============alanz-dev-54589===================
> -------------------------------------------------------------------
> GMS: address=alanz-dev-54589, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63608
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|0] (1) [alanz-dev-54589]
> ** View=[alanz-dev-54589|1] (2) [alanz-dev-54589, AllenMAC-4773]
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> ================alanz-dev-53593=======================
> ---------------------------------------------------------------------
> GMS: address=alanz-dev-53593, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63610
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|13] (1) [alanz-dev-53593], [AllenMAC-4773|13] (1) [AllenMAC-4773]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> The issue happened in our system which uses jGroups for data replication. I turned on all jGroups log, and got some useful log information as the attached. It seems that at some point, a merge request from AllenMAC-4773 was received by alanz-dev-53593, and in that message, mbrs only contained alanz-dev-53593.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2197) Merge doesn't work properly
by Allen Zhao (JIRA)
[ https://issues.jboss.org/browse/JGRP-2197?page=com.atlassian.jira.plugin.... ]
Allen Zhao updated JGRP-2197:
-----------------------------
Affects Version/s: 3.4.2
(was: 3.2.4)
> Merge doesn't work properly
> ---------------------------
>
> Key: JGRP-2197
> URL: https://issues.jboss.org/browse/JGRP-2197
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Allen Zhao
> Assignee: Bela Ban
> Priority: Critical
> Attachments: MergeTest.java, jgroups.log, jgroupsConfig.xml
>
>
> Using the attached jGroups configuration file and sample code based on the Draw example, run two MergeTest instances alanz-dev-54589 and alanz-dev-53593 on one machine, and another instance , AllenMAC-4773 on the second machine; both machines are in the same network connected by a cable.
> Initially all three instances are in the same group, then unplug the cable from the second machine, two groups formed as expected:
> group1: alanz-dev-54589 and alanz-dev-53593
> group2: AllenMAC-4773
> Then plug the cable into the second machine again, the groups merged into one group with all the three members.
> These are good as expected. Keeping doing these by unplug/plug the cable into the second machine, it took around 5 times until the following happened, which is unexpected:
> when AllenMAC-4773 merged into the group composed by alanz-dev-54589 and alanz-dev-53593, it kicked alanz-dev-54589 out, and the two groups formed: MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], and alanz-dev-54589 formed a group by itself.
> Please see the sample code output from the two instances run on the first machine as follows:
> ==============alanz-dev-54589===================
> -------------------------------------------------------------------
> GMS: address=alanz-dev-54589, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63608
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|0] (1) [alanz-dev-54589]
> ** View=[alanz-dev-54589|1] (2) [alanz-dev-54589, AllenMAC-4773]
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> ================alanz-dev-53593=======================
> ---------------------------------------------------------------------
> GMS: address=alanz-dev-53593, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63610
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|13] (1) [alanz-dev-53593], [AllenMAC-4773|13] (1) [AllenMAC-4773]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> The issue happened in our system which uses jGroups for data replication. I turned on all jGroups log, and got some useful log information as the attached. It seems that at some point, a merge request from AllenMAC-4773 was received by alanz-dev-53593, and in that message, mbrs only contained alanz-dev-53593.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi Scott,
I will try the sample application against the latest 10.1.0.Final build.
I would not be surprised that the issue lays somewhere in how ARUJA integrates with eclipselink.
But what appears to be happening is that during the ONSUCCESS / ONCOMPELTION observation of an event takes place at a moment in time where changes have been persisted into the database, but the entity clones used by the unit of work have yet to be published to the server session cache.
So this leads to many "interesting"/un-ince bugs.
>From optimistic locking excpetions, if you try to modify the stale entity you get out of the cache, to incorrect business logic if you let the business logic run and it does not blow up and you did your work based on a stale entity.
So this one, is really a "mess" of a problem, in terms of possible consequences.
I will try to test the sample application against the 10.1.0.Final.
And if that does not work, I will try to see about 10.0.0.Final with hibernate.
What I can confirm is that there is quite a difference of behavior between weblogic transaction management (interceptors) and those in wildfly. Weblogic, will for intances, open a new transaction context implicitly. THe code would not need to be flagged with annotation transaction requires new. IN wildfly, in this scenario the transaction requires new is absolutely need to not get errors stating we are trying to work without transactional context.
In any case, i will report back to you on those two variables.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years