[JBoss JIRA] (WFLY-11343) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11343?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-11343:
-----------------------------------
[~tomjenkinson] I am not familiar at all either. Would you be able to explain a bit why a semaphore would behave differently?
> Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11343
> URL: https://issues.jboss.org/browse/WFLY-11343
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 6.4.18
> Reporter: Shaun Appleton
> Assignee: Tom Jenkinson
> Priority: Major
>
> Description of problem:
> Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem:
> https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f...
> Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner.
> A simple fix could be to just change the lock to a semaphore, so that the other thread can release it.
> Version-Release number of selected component (if applicable):
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start a JTA/JTS tx and call an EJB timer inside it
> 2. Make the transaction timeout
> 3. Capture a thread dump and see a thread like below (0a0818b80 is locked object)
> ---------------------------------------------------------------------------------------------------------
> "Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Locked ownable synchronizers:
> - <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> ---------------------------------------------------------------------------------------------------------
> Actual results:
> Lock being held forever
> Expected results:
> Lock getting released
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11343) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11343?page=com.atlassian.jira.plugin... ]
Kabir Khan reassigned WFLY-11343:
---------------------------------
Assignee: Tom Jenkinson
> Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11343
> URL: https://issues.jboss.org/browse/WFLY-11343
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 6.4.18
> Reporter: Shaun Appleton
> Assignee: Tom Jenkinson
> Priority: Major
>
> Description of problem:
> Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem:
> https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f...
> Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner.
> A simple fix could be to just change the lock to a semaphore, so that the other thread can release it.
> Version-Release number of selected component (if applicable):
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start a JTA/JTS tx and call an EJB timer inside it
> 2. Make the transaction timeout
> 3. Capture a thread dump and see a thread like below (0a0818b80 is locked object)
> ---------------------------------------------------------------------------------------------------------
> "Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Locked ownable synchronizers:
> - <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> ---------------------------------------------------------------------------------------------------------
> Actual results:
> Lock being held forever
> Expected results:
> Lock getting released
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Srinivas ev commented on WFLY-11374:
------------------------------------
Enabled Debug logs. I am not understanding what is happening in the background.
[^rotateserver_active.log] [^rotateserver_backup.log]
I can see connector pairs are having same hostnames instead of two different.
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Reporter: Srinivas ev
> Assignee: Jason Greene
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Srinivas ev updated WFLY-11374:
-------------------------------
Attachment: rotateserver_active.log
rotateserver_backup.log
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Reporter: Srinivas ev
> Assignee: Jason Greene
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11384) StatefulFailoverTestCase fails intermittently
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11384?page=com.atlassian.jira.plugin... ]
Radoslav Husar edited comment on WFLY-11384 at 11/22/18 5:56 AM:
-----------------------------------------------------------------
Most likely another Infinispan clean shutdown issue; possibly related to ISPN-9701 and exacerbated by fix for WFLY-11036.
{noformat}
23:38:09,562 ERROR [org.infinispan.commons.tx.TransactionImpl] (default task-2) ISPN000926: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[node-1, node-2], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[SessionCreationMetaDataKey(D_qoJ7pRmpOfYrvxNXq-dVDCW5IaIPIYz2foDUCF), SessionAttributesKey(D_qoJ7pRmpOfYrvxNXq-dVDCW5IaIPIYz2foDUCF), SessionAccessMetaDataKey(D_qoJ7pRmpOfYrvxNXq-dVDCW5IaIPIYz2foDUCF)], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.synchronization.SyncLocalTransaction@96} org.infinispan.transaction.synchronization.SynchronizationAdapter@b5: org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:148)
at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
at org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:346)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was (Author: rhusar):
Most likely another Infinispan clean shutdown issue; possibly excerbrated by fix for WFLY-11036.
{noformat}
23:38:09,562 ERROR [org.infinispan.commons.tx.TransactionImpl] (default task-2) ISPN000926: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[node-1, node-2], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[SessionCreationMetaDataKey(D_qoJ7pRmpOfYrvxNXq-dVDCW5IaIPIYz2foDUCF), SessionAttributesKey(D_qoJ7pRmpOfYrvxNXq-dVDCW5IaIPIYz2foDUCF), SessionAccessMetaDataKey(D_qoJ7pRmpOfYrvxNXq-dVDCW5IaIPIYz2foDUCF)], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.synchronization.SyncLocalTransaction@96} org.infinispan.transaction.synchronization.SynchronizationAdapter@b5: org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:148)
at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
at org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:346)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> StatefulFailoverTestCase fails intermittently
> ---------------------------------------------
>
> Key: WFLY-11384
> URL: https://issues.jboss.org/browse/WFLY-11384
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 15.0.0.Beta1
> Environment: Any
> Reporter: Ondrej Kotek
> Assignee: Paul Ferraro
> Priority: Major
>
> The tests of {{org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase}} occasionally fail, for example:
> {noformat}
> [ERROR] Failures:
> [ERROR] StatefulFailoverTestCase.jmsConnectionFactoryFailover:166->failover:193->queryCount:315 expected:<200> but was:<500>
> [ERROR] StatefulFailoverTestCase.nestedBeanFailover:286->queryCount:315 expected:<200> but was:<500>
> [ERROR] StatefulFailoverTestCase.noFailover:117 expected:<1> but was:<3>
> {noformat}
> or
> {noformat}
> [ERROR] Failures:
> [ERROR] StatefulFailoverTestCase.nestedBeanFailover:286->queryCount:315 expected:<200> but was:<500>
> [ERROR] StatefulFailoverTestCase.noFailover:117->queryCount:315 expected:<200> but was:<500>
> [ERROR] StatefulFailoverTestCase.simpleFailover:145->failover:193->queryCount:315 expected:<200> but was:<500>
> {noformat}
> connectionFactoryFailover: https://ci.wildfly.org/project.html?projectId=WF&testNameId=-822829635945...
> noFailover: https://ci.wildfly.org/project.html?projectId=WF&testNameId=-574944609062...
> jmsConnectionFactoryFailover: https://ci.wildfly.org/project.html?projectId=WF&testNameId=3564603678560...
> simpleFailover: https://ci.wildfly.org/project.html?projectId=WF&testNameId=4824753507849...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months