[JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS).
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2623:
--------------------------------
Fix Version/s: 5.next
(was: 5.3.0.Final)
> Check Glassfish-to-Narayana interoperability (via JTS).
> -------------------------------------------------------
>
> Key: JBTM-2623
> URL: https://issues.jboss.org/browse/JBTM-2623
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: JTS
> Affects Versions: 5.2.13.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.next
>
>
> This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS).
> Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL.
> \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279]
> XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown:
> {quote}
> javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process
> at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695)
> at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61)
> at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377)
> at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352)
> at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399)
> at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55)
> at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330)
> at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701)
> at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588)
> at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255)
> at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251)
> at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968)
> at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597)
> at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360)
> at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138)
> at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
> at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216)
> at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73)
> at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24)
> at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
> at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48)
> at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
> at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
> at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226)
> at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418)
> at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
> at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200)
> at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
> at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240)
> at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
> at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
> at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210)
> at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118)
> at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
> at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
> at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
> at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
> at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
> at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
> at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
> at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)
> at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
> at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)
> at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)
> at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)
> at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
> at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
> at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
> at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
> at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
> at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
> at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
> at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2624:
--------------------------------
Fix Version/s: 5.next
(was: 5.3.0.Final)
> Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2624
> URL: https://issues.jboss.org/browse/JBTM-2624
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.next
>
>
> {quote}
> We have several management ways in Karaf :
> * mbeans (no need to rewrap them)
> * shell commands
> * a servlet for the felix web console (used by the community)
> * a hawtio plugin (used by fuse)
> The first two are the most important imho.
> {quote}
> the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (JBTM-2583) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2583.
-------------------------------
> Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.3.0.Final
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months