[JBoss JIRA] (JBTM-3255) Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use`
by Thomas Jenkinson (Jira)
[ https://issues.redhat.com/browse/JBTM-3255?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on JBTM-3255:
----------------------------------------
Hi [~ochaloup] how did you determine RemoteEJBClientStatefulBeanFailoverTestCase was not finished properly?
> Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use`
> -----------------------------------------------------------------------------------------------------
>
> Key: JBTM-3255
> URL: https://issues.redhat.com/browse/JBTM-3255
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
>
> There could be observed intermittent failures of AS_TESTS in Narayana CI where the job fails with error {{The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090.}}[1]
> The reason seems to be there is probably unfinished application server running from the prior testsuite module.
> Here we talk about the second server which starts the port `10090` as the management port.
> The arquillian starts the `multinode` module and the first test fails with error that the WildFly can't be started as port can't be bound.
> It could be that there is either some process occupying the port `10090` on the Linux machine.
> But the more probable is that the prior test which is in `clustering` as `org.jboss.as.test.clustering.cluster.ejb2.stateful.failover.RemoteEJBClientStatefulBeanFailoverTestCase` was not finished properly.
> The log files does not show any particular trouble though.
> [1]
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.818 s <<< FAILURE! - in org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase
> [ERROR] org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase Time elapsed: 3.818 s <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.LifecycleException:
> The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.failDueToRunning(ManagedDeployableContainer.java:323)
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:81)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:123)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
> at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
> at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3255) Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use`
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created JBTM-3255:
--------------------------------------
Summary: Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use`
Key: JBTM-3255
URL: https://issues.redhat.com/browse/JBTM-3255
Project: JBoss Transaction Manager
Issue Type: Bug
Components: Testing
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
There could be observed intermittent failures of AS_TESTS in Narayana CI where the job fails with error {{The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090.}}[1]
The reason seems to be there is probably unfinished application server running from the prior testsuite module.
Here we talk about the second server which starts the port `10090` as the management port.
The arquillian starts the `multinode` module and the first test fails with error that the WildFly can't be started as port can't be bound.
It could be that there is either some process occupying the port `10090` on the Linux machine.
But the more probable is that the prior test which is in `clustering` as `org.jboss.as.test.clustering.cluster.ejb2.stateful.failover.RemoteEJBClientStatefulBeanFailoverTestCase` was not finished properly.
The log files does not show any particular trouble though.
[1]
{code}
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.818 s <<< FAILURE! - in org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase
[ERROR] org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase Time elapsed: 3.818 s <<< ERROR!
org.jboss.arquillian.container.spi.client.container.LifecycleException:
The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.failDueToRunning(ManagedDeployableContainer.java:323)
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:81)
at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:123)
at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens
by Thomas Jenkinson (Jira)
[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on JBTM-3210:
----------------------------------------
[~ochaloup] I reopened so I could mark the (new, prospective) 5.9.9.Final version (which is as yet, unreleased) too: https://github.com/jbosstm/narayana/commits/5.9
We can re-close the issue when 5.9.9.Final is released
> Recovery listener gets stuck with processing when unexpected exception happens
> ------------------------------------------------------------------------------
>
> Key: JBTM-3210
> URL: https://issues.redhat.com/browse/JBTM-3210
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.9.8.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.10.0.Final, 5.9.9.Final
>
> Attachments: logs.zip
>
>
> If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call.
> The stack trace of the {{ISE}} is like this
> {code}
> ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
> Stuck connection is like this
> {code}
> "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101)
> - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88)
> {code}
> Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens
by Thomas Jenkinson (Jira)
[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson resolved JBTM-3210.
------------------------------------
Resolution: Done
> Recovery listener gets stuck with processing when unexpected exception happens
> ------------------------------------------------------------------------------
>
> Key: JBTM-3210
> URL: https://issues.redhat.com/browse/JBTM-3210
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.9.8.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.9.9.Final, 5.10.0.Final
>
> Attachments: logs.zip
>
>
> If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call.
> The stack trace of the {{ISE}} is like this
> {code}
> ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
> Stuck connection is like this
> {code}
> "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101)
> - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88)
> {code}
> Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens
by Thomas Jenkinson (Jira)
[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson reopened JBTM-3210:
------------------------------------
> Recovery listener gets stuck with processing when unexpected exception happens
> ------------------------------------------------------------------------------
>
> Key: JBTM-3210
> URL: https://issues.redhat.com/browse/JBTM-3210
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.9.8.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.10.0.Final, 5.9.9.Final
>
> Attachments: logs.zip
>
>
> If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call.
> The stack trace of the {{ISE}} is like this
> {code}
> ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
> Stuck connection is like this
> {code}
> "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101)
> - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88)
> {code}
> Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens
by Thomas Jenkinson (Jira)
[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson updated JBTM-3210:
-----------------------------------
Fix Version/s: 5.9.9.Final
> Recovery listener gets stuck with processing when unexpected exception happens
> ------------------------------------------------------------------------------
>
> Key: JBTM-3210
> URL: https://issues.redhat.com/browse/JBTM-3210
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.9.8.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.10.0.Final, 5.9.9.Final
>
> Attachments: logs.zip
>
>
> If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call.
> The stack trace of the {{ISE}} is like this
> {code}
> ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
> Stuck connection is like this
> {code}
> "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101)
> - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88)
> {code}
> Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3210:
-----------------------------------
Fix Version/s: 5.10.0.Final
> Recovery listener gets stuck with processing when unexpected exception happens
> ------------------------------------------------------------------------------
>
> Key: JBTM-3210
> URL: https://issues.redhat.com/browse/JBTM-3210
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.9.8.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.10.0.Final
>
> Attachments: logs.zip
>
>
> If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call.
> The stack trace of the {{ISE}} is like this
> {code}
> ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
> Stuck connection is like this
> {code}
> "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101)
> - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88)
> {code}
> Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka closed JBTM-3210.
----------------------------------
> Recovery listener gets stuck with processing when unexpected exception happens
> ------------------------------------------------------------------------------
>
> Key: JBTM-3210
> URL: https://issues.redhat.com/browse/JBTM-3210
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.9.8.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.10.0.Final
>
> Attachments: logs.zip
>
>
> If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call.
> The stack trace of the {{ISE}} is like this
> {code}
> ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
> Stuck connection is like this
> {code}
> "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101)
> - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService)
> at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88)
> {code}
> Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months