[JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-2614:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from VERIFIED to CLOSED
> JCA TransactionImporter should be thread safe
> ---------------------------------------------
>
> Key: JBTM-2614
> URL: https://issues.jboss.org/browse/JBTM-2614
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA
> Affects Versions: 5.2.12.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.35, 5.2.13.Final
>
>
> I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int).
> If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events:
> T1: call importTransaction for XID1
> T2: call importTransaction for XID1
> T1: getImportedTransaction returns null
> T2: getImportedTransaction returns null
> T1: create new transaction, add to map
> T2: create new transaction, add to map (overwriting T1's)
> There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JBTM-2837) Server being stuck during shudown when transaction probe op is called
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2837?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #1119 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> Server being stuck during shudown when transaction probe op is called
> ---------------------------------------------------------------------
>
> Key: JBTM-2837
> URL: https://issues.jboss.org/browse/JBTM-2837
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.5.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Attachments: server.log, stacktrace1.log
>
>
> I do experience server to be stuck (in intermittent way) during shutdown. I need to use afterwards {{kill -9}} to stop it.
> From my investigation it seems that it's caused by fact that {{jboss-cli}} operation {{:probe}} does cause {{XARecoveryModule.periodicWorkFirstPass}} being called
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> That way {{scanState}} is left at value ScanStates.BETWEEN_PASSES [1]
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> Now when shutdown of container is being run (you can check attached {{server.log}})
> the periodic recovery is stopped and the {{scanState}} is left as it is. At that point
> call of {{XARecoveryModule#removeXAResourceRecoveryHelper}} causes thread waits for state {{IDLE}} ifinintely. https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> You can consult thread dump from time when server gets stuck {{stacktrace1.log}}.
> [1]
> {code}
> Thread [management-handler-thread - 5] (Suspended (breakpoint at line 149 in XARecoveryModule))
> owns: XARecoveryModule (id=219)
> owns: AtomicAction (id=844)
> owns: ObjStoreBrowser (id=845)
> XARecoveryModule.periodicWorkFirstPass() line: 149
> XARecoveryModule.getNewXAResource(Xid) line: 272
> XARecoveryModule.getNewXAResource(XAResourceRecord) line: 310
> XAResourceRecord.getNewXAResource() line: 1303
> XAResourceRecord.restore_state(InputObjectState, int) line: 1054
> AtomicAction(BasicAction).restore_state(InputObjectState, int) line: 1180
> AtomicAction(BasicAction).activate(String) line: 488
> AtomicAction(BasicAction).activate() line: 451
> ActionBean$GenericAtomicActionWrapper.activate() line: 391
> ActionBean.createWrapper(UidWrapper, boolean) line: 107
> ActionBean.<init>(UidWrapper) line: 93
> NativeConstructorAccessorImpl.newInstance0(Constructor<?>, Object[]) line: not available [native method]
> NativeConstructorAccessorImpl.newInstance(Object[]) line: 62
> DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45
> Constructor<T>.newInstance(Object...) line: 423
> UidWrapper.createMBean() line: 196
> ObjStoreBrowser.createBean(Uid, String) line: 481
> ObjStoreBrowser.probe() line: 435
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> Trampoline.invoke(Method, Object, Object[]) line: 71
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> MethodUtil.invoke(Method, Object, Object[]) line: 275
> StandardMBeanIntrospector.invokeM2(Method, Object, Object[], Object) line: 112
> StandardMBeanIntrospector.invokeM2(Object, Object, Object[], Object) line: 46
> StandardMBeanIntrospector(MBeanIntrospector<M>).invokeM(M, Object, Object[], Object) line: 237
> PerInterface<M>.invoke(Object, String, Object[], String[], Object) line: 138
> StandardMBeanSupport(MBeanSupport<M>).invoke(String, Object[], String[]) line: 252
> DefaultMBeanServerInterceptor.invoke(ObjectName, String, Object[], String[]) line: 819
> JmxMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 801
> PluggableMBeanServerImpl$TcclMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 1512
> PluggableMBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 731
> LogStoreProbeHandler.probeTransactions(MBeanServer, boolean) line: 157
> LogStoreProbeHandler.execute(OperationContext, ModelNode) line: 186
> OperationContextImpl(AbstractOperationContext).executeStep(AbstractOperationContext$Step) line: 921
> OperationContextImpl(AbstractOperationContext).processStages() line: 664
> OperationContextImpl(AbstractOperationContext).executeOperation() line: 383
> OperationContextImpl.executeOperation() line: 1390
> ModelControllerImpl.internalExecute(ModelNode, OperationMessageHandler, ModelController$OperationTransactionControl, OperationAttachments, OperationStepHandler, boolean, boolean) line: 419
> ModelControllerImpl.lambda$execute$1(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> 277244299.run() line: not available
> SecurityIdentity.runAs(PrivilegedAction<T>) line: 193
> ModelControllerImpl.execute(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelNode, int, ManagementRequestContext<Void>, CompletedCallback) line: 217
> ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler$ExecuteRequestHandler, ModelNode, int, ManagementRequestContext, ModelControllerClientOperationHandler$CompletedCallback) line: 137
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 161
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 157
> SecurityIdentity.runAs(PrivilegedExceptionAction<T>) line: 212
> AccessAuditContext.doAs(SecurityIdentity, InetAddress, PrivilegedExceptionAction<T>) line: 185
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ManagementRequestContext<Void>) line: 157
> ManagementRequestContextImpl$1.doExecute() line: 70
> ManagementRequestContextImpl$1(ManagementRequestContextImpl$AsyncTaskRunner).run() line: 160
> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142
> ThreadPoolExecutor$Worker.run() line: 617
> JBossThread(Thread).run() line: 745
> JBossThread.run() line: 320
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JBTM-2837) Server being stuck during shudown when transaction probe op is called
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2837?page=com.atlassian.jira.plugin.... ]
Michael Musgrove edited comment on JBTM-2837 at 1/17/17 12:45 PM:
------------------------------------------------------------------
I have been unable to reproduce the issue on my laptop but code analysis does show:
# the hang is possible;
# the linked jira contains a stacktrace that shows removeXAResourceRecoveryHelper waiting for the scanState to change to IDLE
So, I will go ahead and apply the fix mentioned above
was (Author: mmusgrov):
I have been unable to reproduce the issue on my laptop but code analysis does show:
# the hang is possible;
# the linked jira contains a stacktrace that shows removeXAResourceRecoveryHelper waiting for the scanState to change to IDLE
So, I will go ahead and apply the fix mentioned above
> Server being stuck during shudown when transaction probe op is called
> ---------------------------------------------------------------------
>
> Key: JBTM-2837
> URL: https://issues.jboss.org/browse/JBTM-2837
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.5.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Attachments: server.log, stacktrace1.log
>
>
> I do experience server to be stuck (in intermittent way) during shutdown. I need to use afterwards {{kill -9}} to stop it.
> From my investigation it seems that it's caused by fact that {{jboss-cli}} operation {{:probe}} does cause {{XARecoveryModule.periodicWorkFirstPass}} being called
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> That way {{scanState}} is left at value ScanStates.BETWEEN_PASSES [1]
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> Now when shutdown of container is being run (you can check attached {{server.log}})
> the periodic recovery is stopped and the {{scanState}} is left as it is. At that point
> call of {{XARecoveryModule#removeXAResourceRecoveryHelper}} causes thread waits for state {{IDLE}} ifinintely. https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> You can consult thread dump from time when server gets stuck {{stacktrace1.log}}.
> [1]
> {code}
> Thread [management-handler-thread - 5] (Suspended (breakpoint at line 149 in XARecoveryModule))
> owns: XARecoveryModule (id=219)
> owns: AtomicAction (id=844)
> owns: ObjStoreBrowser (id=845)
> XARecoveryModule.periodicWorkFirstPass() line: 149
> XARecoveryModule.getNewXAResource(Xid) line: 272
> XARecoveryModule.getNewXAResource(XAResourceRecord) line: 310
> XAResourceRecord.getNewXAResource() line: 1303
> XAResourceRecord.restore_state(InputObjectState, int) line: 1054
> AtomicAction(BasicAction).restore_state(InputObjectState, int) line: 1180
> AtomicAction(BasicAction).activate(String) line: 488
> AtomicAction(BasicAction).activate() line: 451
> ActionBean$GenericAtomicActionWrapper.activate() line: 391
> ActionBean.createWrapper(UidWrapper, boolean) line: 107
> ActionBean.<init>(UidWrapper) line: 93
> NativeConstructorAccessorImpl.newInstance0(Constructor<?>, Object[]) line: not available [native method]
> NativeConstructorAccessorImpl.newInstance(Object[]) line: 62
> DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45
> Constructor<T>.newInstance(Object...) line: 423
> UidWrapper.createMBean() line: 196
> ObjStoreBrowser.createBean(Uid, String) line: 481
> ObjStoreBrowser.probe() line: 435
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> Trampoline.invoke(Method, Object, Object[]) line: 71
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> MethodUtil.invoke(Method, Object, Object[]) line: 275
> StandardMBeanIntrospector.invokeM2(Method, Object, Object[], Object) line: 112
> StandardMBeanIntrospector.invokeM2(Object, Object, Object[], Object) line: 46
> StandardMBeanIntrospector(MBeanIntrospector<M>).invokeM(M, Object, Object[], Object) line: 237
> PerInterface<M>.invoke(Object, String, Object[], String[], Object) line: 138
> StandardMBeanSupport(MBeanSupport<M>).invoke(String, Object[], String[]) line: 252
> DefaultMBeanServerInterceptor.invoke(ObjectName, String, Object[], String[]) line: 819
> JmxMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 801
> PluggableMBeanServerImpl$TcclMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 1512
> PluggableMBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 731
> LogStoreProbeHandler.probeTransactions(MBeanServer, boolean) line: 157
> LogStoreProbeHandler.execute(OperationContext, ModelNode) line: 186
> OperationContextImpl(AbstractOperationContext).executeStep(AbstractOperationContext$Step) line: 921
> OperationContextImpl(AbstractOperationContext).processStages() line: 664
> OperationContextImpl(AbstractOperationContext).executeOperation() line: 383
> OperationContextImpl.executeOperation() line: 1390
> ModelControllerImpl.internalExecute(ModelNode, OperationMessageHandler, ModelController$OperationTransactionControl, OperationAttachments, OperationStepHandler, boolean, boolean) line: 419
> ModelControllerImpl.lambda$execute$1(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> 277244299.run() line: not available
> SecurityIdentity.runAs(PrivilegedAction<T>) line: 193
> ModelControllerImpl.execute(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelNode, int, ManagementRequestContext<Void>, CompletedCallback) line: 217
> ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler$ExecuteRequestHandler, ModelNode, int, ManagementRequestContext, ModelControllerClientOperationHandler$CompletedCallback) line: 137
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 161
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 157
> SecurityIdentity.runAs(PrivilegedExceptionAction<T>) line: 212
> AccessAuditContext.doAs(SecurityIdentity, InetAddress, PrivilegedExceptionAction<T>) line: 185
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ManagementRequestContext<Void>) line: 157
> ManagementRequestContextImpl$1.doExecute() line: 70
> ManagementRequestContextImpl$1(ManagementRequestContextImpl$AsyncTaskRunner).run() line: 160
> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142
> ThreadPoolExecutor$Worker.run() line: 617
> JBossThread(Thread).run() line: 745
> JBossThread.run() line: 320
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JBTM-2837) Server being stuck during shudown when transaction probe op is called
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2837?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2837:
----------------------------------------
I have been unable to reproduce the issue on my laptop but code analysis does show:
# the hang is possible;
# the linked jira contains a stacktrace that shows removeXAResourceRecoveryHelper waiting for the scanState to change to IDLE
So, I will go ahead and apply the fix mentioned above
> Server being stuck during shudown when transaction probe op is called
> ---------------------------------------------------------------------
>
> Key: JBTM-2837
> URL: https://issues.jboss.org/browse/JBTM-2837
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.5.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Attachments: server.log, stacktrace1.log
>
>
> I do experience server to be stuck (in intermittent way) during shutdown. I need to use afterwards {{kill -9}} to stop it.
> From my investigation it seems that it's caused by fact that {{jboss-cli}} operation {{:probe}} does cause {{XARecoveryModule.periodicWorkFirstPass}} being called
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> That way {{scanState}} is left at value ScanStates.BETWEEN_PASSES [1]
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> Now when shutdown of container is being run (you can check attached {{server.log}})
> the periodic recovery is stopped and the {{scanState}} is left as it is. At that point
> call of {{XARecoveryModule#removeXAResourceRecoveryHelper}} causes thread waits for state {{IDLE}} ifinintely. https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> You can consult thread dump from time when server gets stuck {{stacktrace1.log}}.
> [1]
> {code}
> Thread [management-handler-thread - 5] (Suspended (breakpoint at line 149 in XARecoveryModule))
> owns: XARecoveryModule (id=219)
> owns: AtomicAction (id=844)
> owns: ObjStoreBrowser (id=845)
> XARecoveryModule.periodicWorkFirstPass() line: 149
> XARecoveryModule.getNewXAResource(Xid) line: 272
> XARecoveryModule.getNewXAResource(XAResourceRecord) line: 310
> XAResourceRecord.getNewXAResource() line: 1303
> XAResourceRecord.restore_state(InputObjectState, int) line: 1054
> AtomicAction(BasicAction).restore_state(InputObjectState, int) line: 1180
> AtomicAction(BasicAction).activate(String) line: 488
> AtomicAction(BasicAction).activate() line: 451
> ActionBean$GenericAtomicActionWrapper.activate() line: 391
> ActionBean.createWrapper(UidWrapper, boolean) line: 107
> ActionBean.<init>(UidWrapper) line: 93
> NativeConstructorAccessorImpl.newInstance0(Constructor<?>, Object[]) line: not available [native method]
> NativeConstructorAccessorImpl.newInstance(Object[]) line: 62
> DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45
> Constructor<T>.newInstance(Object...) line: 423
> UidWrapper.createMBean() line: 196
> ObjStoreBrowser.createBean(Uid, String) line: 481
> ObjStoreBrowser.probe() line: 435
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> Trampoline.invoke(Method, Object, Object[]) line: 71
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> MethodUtil.invoke(Method, Object, Object[]) line: 275
> StandardMBeanIntrospector.invokeM2(Method, Object, Object[], Object) line: 112
> StandardMBeanIntrospector.invokeM2(Object, Object, Object[], Object) line: 46
> StandardMBeanIntrospector(MBeanIntrospector<M>).invokeM(M, Object, Object[], Object) line: 237
> PerInterface<M>.invoke(Object, String, Object[], String[], Object) line: 138
> StandardMBeanSupport(MBeanSupport<M>).invoke(String, Object[], String[]) line: 252
> DefaultMBeanServerInterceptor.invoke(ObjectName, String, Object[], String[]) line: 819
> JmxMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 801
> PluggableMBeanServerImpl$TcclMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 1512
> PluggableMBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 731
> LogStoreProbeHandler.probeTransactions(MBeanServer, boolean) line: 157
> LogStoreProbeHandler.execute(OperationContext, ModelNode) line: 186
> OperationContextImpl(AbstractOperationContext).executeStep(AbstractOperationContext$Step) line: 921
> OperationContextImpl(AbstractOperationContext).processStages() line: 664
> OperationContextImpl(AbstractOperationContext).executeOperation() line: 383
> OperationContextImpl.executeOperation() line: 1390
> ModelControllerImpl.internalExecute(ModelNode, OperationMessageHandler, ModelController$OperationTransactionControl, OperationAttachments, OperationStepHandler, boolean, boolean) line: 419
> ModelControllerImpl.lambda$execute$1(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> 277244299.run() line: not available
> SecurityIdentity.runAs(PrivilegedAction<T>) line: 193
> ModelControllerImpl.execute(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelNode, int, ManagementRequestContext<Void>, CompletedCallback) line: 217
> ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler$ExecuteRequestHandler, ModelNode, int, ManagementRequestContext, ModelControllerClientOperationHandler$CompletedCallback) line: 137
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 161
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 157
> SecurityIdentity.runAs(PrivilegedExceptionAction<T>) line: 212
> AccessAuditContext.doAs(SecurityIdentity, InetAddress, PrivilegedExceptionAction<T>) line: 185
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ManagementRequestContext<Void>) line: 157
> ManagementRequestContextImpl$1.doExecute() line: 70
> ManagementRequestContextImpl$1(ManagementRequestContextImpl$AsyncTaskRunner).run() line: 160
> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142
> ThreadPoolExecutor$Worker.run() line: 617
> JBossThread(Thread).run() line: 745
> JBossThread.run() line: 320
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JBTM-2837) Server being stuck during shudown when transaction probe op is called
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2837?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2837:
----------------------------------------
Other than timeliness, I do not foresee any issues with calling periodicWorkSecondPass during shutdown. However, that said, my analysis indicates that this is a test issue - I added a comment on [https://issues.jboss.org/browse/JBEAP-8237|http://example.com] explaining my rationale.
> Server being stuck during shudown when transaction probe op is called
> ---------------------------------------------------------------------
>
> Key: JBTM-2837
> URL: https://issues.jboss.org/browse/JBTM-2837
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.5.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Attachments: server.log, stacktrace1.log
>
>
> I do experience server to be stuck (in intermittent way) during shutdown. I need to use afterwards {{kill -9}} to stop it.
> From my investigation it seems that it's caused by fact that {{jboss-cli}} operation {{:probe}} does cause {{XARecoveryModule.periodicWorkFirstPass}} being called
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> That way {{scanState}} is left at value ScanStates.BETWEEN_PASSES [1]
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> Now when shutdown of container is being run (you can check attached {{server.log}})
> the periodic recovery is stopped and the {{scanState}} is left as it is. At that point
> call of {{XARecoveryModule#removeXAResourceRecoveryHelper}} causes thread waits for state {{IDLE}} ifinintely. https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> You can consult thread dump from time when server gets stuck {{stacktrace1.log}}.
> [1]
> {code}
> Thread [management-handler-thread - 5] (Suspended (breakpoint at line 149 in XARecoveryModule))
> owns: XARecoveryModule (id=219)
> owns: AtomicAction (id=844)
> owns: ObjStoreBrowser (id=845)
> XARecoveryModule.periodicWorkFirstPass() line: 149
> XARecoveryModule.getNewXAResource(Xid) line: 272
> XARecoveryModule.getNewXAResource(XAResourceRecord) line: 310
> XAResourceRecord.getNewXAResource() line: 1303
> XAResourceRecord.restore_state(InputObjectState, int) line: 1054
> AtomicAction(BasicAction).restore_state(InputObjectState, int) line: 1180
> AtomicAction(BasicAction).activate(String) line: 488
> AtomicAction(BasicAction).activate() line: 451
> ActionBean$GenericAtomicActionWrapper.activate() line: 391
> ActionBean.createWrapper(UidWrapper, boolean) line: 107
> ActionBean.<init>(UidWrapper) line: 93
> NativeConstructorAccessorImpl.newInstance0(Constructor<?>, Object[]) line: not available [native method]
> NativeConstructorAccessorImpl.newInstance(Object[]) line: 62
> DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45
> Constructor<T>.newInstance(Object...) line: 423
> UidWrapper.createMBean() line: 196
> ObjStoreBrowser.createBean(Uid, String) line: 481
> ObjStoreBrowser.probe() line: 435
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> Trampoline.invoke(Method, Object, Object[]) line: 71
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 498
> MethodUtil.invoke(Method, Object, Object[]) line: 275
> StandardMBeanIntrospector.invokeM2(Method, Object, Object[], Object) line: 112
> StandardMBeanIntrospector.invokeM2(Object, Object, Object[], Object) line: 46
> StandardMBeanIntrospector(MBeanIntrospector<M>).invokeM(M, Object, Object[], Object) line: 237
> PerInterface<M>.invoke(Object, String, Object[], String[], Object) line: 138
> StandardMBeanSupport(MBeanSupport<M>).invoke(String, Object[], String[]) line: 252
> DefaultMBeanServerInterceptor.invoke(ObjectName, String, Object[], String[]) line: 819
> JmxMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 801
> PluggableMBeanServerImpl$TcclMBeanServer.invoke(ObjectName, String, Object[], String[]) line: 1512
> PluggableMBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 731
> LogStoreProbeHandler.probeTransactions(MBeanServer, boolean) line: 157
> LogStoreProbeHandler.execute(OperationContext, ModelNode) line: 186
> OperationContextImpl(AbstractOperationContext).executeStep(AbstractOperationContext$Step) line: 921
> OperationContextImpl(AbstractOperationContext).processStages() line: 664
> OperationContextImpl(AbstractOperationContext).executeOperation() line: 383
> OperationContextImpl.executeOperation() line: 1390
> ModelControllerImpl.internalExecute(ModelNode, OperationMessageHandler, ModelController$OperationTransactionControl, OperationAttachments, OperationStepHandler, boolean, boolean) line: 419
> ModelControllerImpl.lambda$execute$1(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> 277244299.run() line: not available
> SecurityIdentity.runAs(PrivilegedAction<T>) line: 193
> ModelControllerImpl.execute(Operation, OperationMessageHandler, ModelController$OperationTransactionControl) line: 240
> ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelNode, int, ManagementRequestContext<Void>, CompletedCallback) line: 217
> ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler$ExecuteRequestHandler, ModelNode, int, ManagementRequestContext, ModelControllerClientOperationHandler$CompletedCallback) line: 137
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 161
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run() line: 157
> SecurityIdentity.runAs(PrivilegedExceptionAction<T>) line: 212
> AccessAuditContext.doAs(SecurityIdentity, InetAddress, PrivilegedExceptionAction<T>) line: 185
> ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ManagementRequestContext<Void>) line: 157
> ManagementRequestContextImpl$1.doExecute() line: 70
> ManagementRequestContextImpl$1(ManagementRequestContextImpl$AsyncTaskRunner).run() line: 160
> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142
> ThreadPoolExecutor$Worker.run() line: 617
> JBossThread(Thread).run() line: 745
> JBossThread.run() line: 320
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (JBTM-2708) Test does not close FileInputStream
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2708?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-2708:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from VERIFIED to CLOSED
> Test does not close FileInputStream
> -----------------------------------
>
> Key: JBTM-2708
> URL: https://issues.jboss.org/browse/JBTM-2708
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Testing
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.35, 5.3.4.Final
>
>
> {code}
> public XARRTestResource(String xarrHelper, File file) throws IOException {
> this.xarrHelper = xarrHelper;
> this.file = file;
> DataInputStream fis = new DataInputStream(new FileInputStream(file));
> final int formatId = fis.readInt();
> final int gtrid_length = fis.readInt();
> final byte[] gtrid = new byte[gtrid_length];
> fis.read(gtrid, 0, gtrid_length);
> final int bqual_length = fis.readInt();
> final byte[] bqual = new byte[bqual_length];
> fis.read(bqual, 0, bqual_length);
> xids.put(file, new Xid() {
> @Override
> public byte[] getGlobalTransactionId() {
> return gtrid;
> }
> @Override
> public int getFormatId() {
> return formatId;
> }
> @Override
> public byte[] getBranchQualifier() {
> return bqual;
> }
> });
> fis.close();
> }
> {code}
> Spotted while working on JBTM-2614 backport
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months