[JBoss JIRA] (JBTM-2213) Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2213?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-2213:
--------------------------------
Reporter: Gytis Trikleris (was: Tom Jenkinson)
> Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba
> ------------------------------------------------------------------------------------------
>
> Key: JBTM-2213
> URL: https://issues.jboss.org/browse/JBTM-2213
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: TXFramework
> Affects Versions: 5.0.2
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
>
> If you run:
> ./build.sh clean install -DskipTests | grep "org.jboss.narayana.txframework.api.annotation.lifecycle.ba"
> You will see:
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipant.java:[45,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[112,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[154,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[115,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[162,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[57,146] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[115,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[158,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[62,27] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[65,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[118,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
> [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[166,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-1680) Allow 2PC participants to enlist in a compensation-based transaction
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1680?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1680:
--------------------------------
Reporter: Gytis Trikleris (was: Paul Robinson)
> Allow 2PC participants to enlist in a compensation-based transaction
> --------------------------------------------------------------------
>
> Key: JBTM-1680
> URL: https://issues.jboss.org/browse/JBTM-1680
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: TXFramework, XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 6.0.0
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate.
> This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1639?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1639:
--------------------------------
Reporter: Gytis Trikleris (was: Paul Robinson)
> Improve XTS Api for looking up Recovery Manager to prevent developer from poling
> --------------------------------------------------------------------------------
>
> Key: JBTM-1639
> URL: https://issues.jboss.org/browse/JBTM-1639
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Fix For: 6.0.0
>
>
> Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup.
> This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null.
> Two possible solutions:
> Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome.
> Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted.
> To Reproduce
> Put breakpoints on:
> Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads
> XTSATRecoveryManager.setRecoveryManager() // stop on Thread only
> Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM.
> Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-1859) Remove classname Strings from XTS subsystem
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1859?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1859:
--------------------------------
Reporter: Gytis Trikleris (was: Paul Robinson)
> Remove classname Strings from XTS subsystem
> -------------------------------------------
>
> Key: JBTM-1859
> URL: https://issues.jboss.org/browse/JBTM-1859
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Application Server Integration, XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 6.0.0
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe.
> When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details.
> However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName().
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1715:
--------------------------------
Reporter: Gytis Trikleris (was: Paul Robinson)
> NPE when using CompensationManager within an in-flowed WS-BA transaction
> ------------------------------------------------------------------------
>
> Key: JBTM-1715
> URL: https://issues.jboss.org/browse/JBTM-1715
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 6.0.0
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction.
> {quote}
> 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100]
> ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS
> HOT]
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-1507) Review the TXBridge tests usage of Arquillian
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1507?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1507:
--------------------------------
Reporter: Gytis Trikleris (was: Paul Robinson)
> Review the TXBridge tests usage of Arquillian
> ---------------------------------------------
>
> Key: JBTM-1507
> URL: https://issues.jboss.org/browse/JBTM-1507
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Testing, TxBridge
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 6.0.0
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> The TXBridge tests don;t seem to be using Arquillian correctly. There is a servlet that is invoked to do things inside the container. As the tests (should) now run in the container, this should not be needed.
> The tests also seem to have added complexity due to the recovery tests. As the recovery tests need to be able to kill the container, it mandates manual container lifecycle management for *all* tests. We may want to pull out the recovery tests into a separate module.
> We also may want to pull out the DisabledContextPropagationTest into a separate module as they use a modified AS configuration.
> We should also take a general look at how the tests are structured and using Arq.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2256:
-------------------------------------
Implementing the fix will prevent us creating a byteman race condition test case for the issue as it will (assuming the correct recovery modules are configured) no longer be possible for the expiry scanner to start before the Implementationsx.java is loaded.
A comment in the code that explains the issue (i.e. ExpiredEntryMonitor.startUp(); _MUST_ be called after _periodicRecovery = new PeriodicRecovery(threaded, useListener); and provide more details on that) is the best thing to ensure its not reverted, plus Gytis should also cherry-pick the test I have written https://github.com/tomjenkinson/narayana/compare/4.17...JBTM-2256 during verification of the issue. Even though Byteman verification isn't possible, the test could still alert us if something were to change in this area in the future.
On the link I provided above you will see that I have added byteman to verify the failure without the fix. Once the fix is applied the test will hand as the race condition no longer exists so that specific commit should not be cherry-picked but the underlying test can be.
> Race condition between recovery manager initialization and expiry scanner
> -------------------------------------------------------------------------
>
> Key: JBTM-2256
> URL: https://issues.jboss.org/browse/JBTM-2256
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 4.17.23, 5.0.4
>
>
> In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem.
> Swapping these two actions should solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months