[JBoss JIRA] (JBTM-1460) TXBridge test hangs when Arquillian starts the container
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1460?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1460:
-------------------------------------
Added a forum post:
https://community.jboss.org/thread/220986
> TXBridge test hangs when Arquillian starts the container
> --------------------------------------------------------
>
> Key: JBTM-1460
> URL: https://issues.jboss.org/browse/JBTM-1460
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: AS7 master as of 2013-02-05
> Arquillian core: 1.0.0.Final
> Arquillian osgi: 1.0.2.Final
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Attachments: client.log, server.log
>
>
> See: 172.17.131.2/job/btny-pulls-narayana/345/ where the job has hung for about 16hrs.
> From looking at the stack trace in client.log (attached):
> {code}
> at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:107)
> at org.jboss.jbossts.txbridge.tests.inbound.junit.InboundBasicTests.setUp(InboundBasicTests.java:75)
> {code}
> The hang is happening on this line:
> {code}
> controller.start(CONTAINER);
> {code}
> Which is starting the container 'jboss', which is described in the arquillian.xml as:
> {code}
> <container qualifier="jboss" default="true" mode="manual">
> <configuration>
> <property name="javaVmArguments">${server.jvm.args}</property>
> <property name="serverConfig">standalone-xts.xml</property>
> <property name="managementAddress">${node.address}</property>
> </configuration>
> </container>
> {code}
> From looking at server.log (attached) it looks like the server has started and deployed the deployments:
> First of two deployments:
> {code}
> 18:36:32,013 INFO [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "txbridge-inbound-tests-service.war" (runtime-name : "txbridge-inbound-tests-service.war")
> {code}
> Second of two deployments:
> {code}
> 18:36:32,975 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "txbridge-inbound-tests-client.war" (runtime-name : "txbridge-inbound-tests-client.war")
> {code}
> Notice that the output above is that last line of output on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-1460) TXBridge test hangs when Arquillian starts the container
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1460?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1460:
--------------------------------
Attachment: server.log
client.log
> TXBridge test hangs when Arquillian starts the container
> --------------------------------------------------------
>
> Key: JBTM-1460
> URL: https://issues.jboss.org/browse/JBTM-1460
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: AS7 master as of 2013-02-05
> Arquillian core: 1.0.0.Final
> Arquillian osgi: 1.0.2.Final
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Attachments: client.log, server.log
>
>
> See: 172.17.131.2/job/btny-pulls-narayana/345/ where the job has hung for about 16hrs.
> From looking at the stack trace in client.log (attached):
> {code}
> at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:107)
> at org.jboss.jbossts.txbridge.tests.inbound.junit.InboundBasicTests.setUp(InboundBasicTests.java:75)
> {code}
> The hang is happening on this line:
> {code}
> controller.start(CONTAINER);
> {code}
> Which is starting the container 'jboss', which is described in the arquillian.xml as:
> {code}
> <container qualifier="jboss" default="true" mode="manual">
> <configuration>
> <property name="javaVmArguments">${server.jvm.args}</property>
> <property name="serverConfig">standalone-xts.xml</property>
> <property name="managementAddress">${node.address}</property>
> </configuration>
> </container>
> {code}
> From looking at server.log (attached) it looks like the server has started and deployed the deployments:
> First of two deployments:
> {code}
> 18:36:32,013 INFO [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "txbridge-inbound-tests-service.war" (runtime-name : "txbridge-inbound-tests-service.war")
> {code}
> Second of two deployments:
> {code}
> 18:36:32,975 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "txbridge-inbound-tests-client.war" (runtime-name : "txbridge-inbound-tests-client.war")
> {code}
> Notice that the output above is that last line of output on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-1460) TXBridge test hangs when Arquillian starts the container
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1460:
-----------------------------------
Summary: TXBridge test hangs when Arquillian starts the container
Key: JBTM-1460
URL: https://issues.jboss.org/browse/JBTM-1460
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: AS7 master as of 2013-02-05
Arquillian core: 1.0.0.Final
Arquillian osgi: 1.0.2.Final
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See: 172.17.131.2/job/btny-pulls-narayana/345/ where the job has hung for about 16hrs.
>From looking at the stack trace in client.log (attached):
{code}
at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:107)
at org.jboss.jbossts.txbridge.tests.inbound.junit.InboundBasicTests.setUp(InboundBasicTests.java:75)
{code}
The hang is happening on this line:
{code}
controller.start(CONTAINER);
{code}
Which is starting the container 'jboss', which is described in the arquillian.xml as:
{code}
<container qualifier="jboss" default="true" mode="manual">
<configuration>
<property name="javaVmArguments">${server.jvm.args}</property>
<property name="serverConfig">standalone-xts.xml</property>
<property name="managementAddress">${node.address}</property>
</configuration>
</container>
{code}
>From looking at server.log (attached) it looks like the server has started and deployed the deployments:
First of two deployments:
{code}
18:36:32,013 INFO [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "txbridge-inbound-tests-service.war" (runtime-name : "txbridge-inbound-tests-service.war")
{code}
Second of two deployments:
{code}
18:36:32,975 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "txbridge-inbound-tests-client.war" (runtime-name : "txbridge-inbound-tests-client.war")
{code}
Notice that the output above is that last line of output on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-1093) TXFramework Quickstart: Bridging, WS-BA -> JTA
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1093?focusedWorklogId=12428611&page=... ]
Paul Robinson logged work on JBTM-1093:
---------------------------------------
Author: Paul Robinson
Created on: 05/Feb/13 11:51 AM
Start Date: 05/Feb/13 11:51 AM
Worklog Time Spent: 1 hour
Issue Time Tracking
-------------------
Remaining Estimate: 1 hour (was: 6 hours)
Time Spent: 3 hours (was: 2 hours)
Worklog Id: (was: 12428611)
> TXFramework Quickstart: Bridging, WS-BA -> JTA
> ----------------------------------------------
>
> Key: JBTM-1093
> URL: https://issues.jboss.org/browse/JBTM-1093
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: assign
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 3 hours
> Remaining Estimate: 1 hour
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?focusedWorklogId=12428610&page=c... ]
Paul Robinson logged work on JBTM-972:
--------------------------------------
Author: Paul Robinson
Created on: 05/Feb/13 11:35 AM
Start Date: 05/Feb/13 11:34 AM
Worklog Time Spent: 6 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 1 day)
Time Spent: 2 days (was: 1 day, 2 hours)
Worklog Id: (was: 12428610)
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 days
> Remaining Estimate: 0 minutes
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?page=com.atlassian.jira.plugin.s... ]
Paul Robinson updated JBTM-972:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 days
> Remaining Estimate: 0 minutes
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?page=com.atlassian.jira.plugin.s... ]
Paul Robinson updated JBTM-972:
-------------------------------
Git Pull Request: https://github.com/jbosstm/narayana/pull/215, https://github.com/jbosstm/quickstart/pull/62 (was: https://github.com/jbosstm/narayana/pull/215)
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 1 day, 2 hours
> Remaining Estimate: 1 day
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?page=com.atlassian.jira.plugin.s... ]
Paul Robinson updated JBTM-972:
-------------------------------
Git Pull Request: https://github.com/jbosstm/narayana/pull/215, https://github.com/jbosstm/quickstart/pull/62, https://github.com/jbosstm/jboss-as/commit/fac86c7225270e74f547ca19d0ab4f... (was: https://github.com/jbosstm/narayana/pull/215, https://github.com/jbosstm/quickstart/pull/62)
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 1 day, 2 hours
> Remaining Estimate: 1 day
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?page=com.atlassian.jira.plugin.s... ]
Paul Robinson updated JBTM-972:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/215
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 1 day, 2 hours
> Remaining Estimate: 1 day
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JBTM-1369) Benchmark performance difference between JacORB and JDK ORB
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1369?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1369 stopped by Gytis Trikleris.
> Benchmark performance difference between JacORB and JDK ORB
> -----------------------------------------------------------
>
> Key: JBTM-1369
> URL: https://issues.jboss.org/browse/JBTM-1369
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JTS, Performance Testing
> Affects Versions: 4.17.0
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
>
> JBTM-934 added support for the JDK orb to JTS. IOR sizes can range in size from 512 bytes to entirely unbounded, with the ORB being able to add arbitrary data within specific portions. Since the IOR is packed into transaction logs and if the IOR sizes are significantly different we may find that transaction throughput has been improved or degraded. We should run some benchmarks to see what the impact is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months