From issues at jboss.org Thu Feb 2 14:07:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 2 Feb 2017 14:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: David Lloyd created JBTM-2846: --------------------------------- Summary: Thread-safety problem in BasicAction Key: JBTM-2846 URL: https://issues.jboss.org/browse/JBTM-2846 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Affects Versions: 5.4.0.Final Reporter: David Lloyd Priority: Critical It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. Other methods access {{actionStatus}} without regard to concurrently protection, including: * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 2 14:22:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 2 Feb 2017 14:22:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357897#comment-13357897 ] David Lloyd commented on JBTM-2846: ----------------------------------- Note that naively wrapping this method in a synchronized block may result in trouble as well because doBeforeCommit holds a different lock (com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator#_syncLock) during its execution, and other threads can reasonably still be doing work while this is going on. Also that method calls preventCommit() as well, which may result in relevant effects. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 3 11:54:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 3 Feb 2017 11:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358529#comment-13358529 ] RH Bugzilla Integration commented on JBTM-2749: ----------------------------------------------- Petr Penicka changed the Status of [bug 1399703|https://bugzilla.redhat.com/show_bug.cgi?id=1399703] from VERIFIED to CLOSED > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 4.17.37, 5.2.19.Final, 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 6 16:07:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 6 Feb 2017 16:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2847) Static code analysis - check report and fix issues In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2847: ------------------------------------- Summary: Static code analysis - check report and fix issues Key: JBTM-2847 URL: https://issues.jboss.org/browse/JBTM-2847 Project: JBoss Transaction Manager Issue Type: Task Affects Versions: 5.5.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor By going through static code analysis report of changes done during last a half year there are few issues that would be fine to be adjusted. They are following # at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, L614; com.arjuna.ats.internal.jta.transaction.jts.jca, L471 (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L614) the calling method getCurrentTransactionId() potentially could end with NullPointerException (caused by TransactionImple#getTransaction when `final BasicAction current = BasicAction.Current()` is null) # possible resource leak - connection was ommitted to be closed ## org.jboss.narayana.tomcat.jta.integration.TestExecutor ## TestCommitMarkableResourceFailAfterCommitOrphan # inner class SampleLockable of org.jboss.stm.STMVerticle could be static (http://station5.brq.redhat.com:8080/docs/en/findbugs/fb_checker_ref.html#FB.SIC_INNER_SHOULD_BE_STATIC) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 6 16:20:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 6 Feb 2017 16:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2847) Static code analysis - check report and fix issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1125 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Static code analysis - check report and fix issues > -------------------------------------------------- > > Key: JBTM-2847 > URL: https://issues.jboss.org/browse/JBTM-2847 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 5.5.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > By going through static code analysis report of changes done during last a half year there are few issues that would be fine to be adjusted. > They are following > # at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, > L614; com.arjuna.ats.internal.jta.transaction.jts.jca, L471 > (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L614) the calling method getCurrentTransactionId() potentially could end with > NullPointerException (caused by TransactionImple#getTransaction when `final BasicAction current = BasicAction.Current()` is null) > # possible resource leak - connection was ommitted to be closed > ## org.jboss.narayana.tomcat.jta.integration.TestExecutor > ## TestCommitMarkableResourceFailAfterCommitOrphan > # inner class SampleLockable of org.jboss.stm.STMVerticle could be static (http://station5.brq.redhat.com:8080/docs/en/findbugs/fb_checker_ref.html#FB.SIC_INNER_SHOULD_BE_STATIC) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 7 12:38:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Feb 2017 12:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-989) Consider using a common code style throughout Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359961#comment-13359961 ] Michael Musgrove commented on JBTM-989: --------------------------------------- There was a separate discussion via email amongst the members of the team. The consensus was to maintain the status quo, namely: # We recommend the use of the AS7 style, but don't mandate it; # Follow your preferred style (within reason) when working on your own code and respect another's style when working on theirs; # Code style should be consistent throughout the file. > Consider using a common code style throughout Narayana > ------------------------------------------------------ > > Key: JBTM-989 > URL: https://issues.jboss.org/browse/JBTM-989 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 4.17.0.M1/5.0.0.M1 > Reporter: Paul Robinson > Assignee: Tom Jenkinson > > I think we should consider using a common code style throughout the TS project. The benefits of doing this are as follows: > # You can automate code formatting. This is a real productivity boost as you can type away, thinking about your code, rather than the style. When you hit save, or trigger it directly, the code is formatted. > ## This is not possible without a project wide code style as you too frequently re-format code that needs to stay in someone else's personal style. You can't commit this changed code as; a) it may annoy the "owner" and b) it results in a change that can't be diffed (every line may be changed). > # We get consistency over the whole project, making it easier to read code written by others. > # We have to do this anyway for code we maintain inside the JBossAS project as the project refuses to build if it doesn't adhere to their style. > Personally, I like the style I've used for the last 10 years. I find it harder to read code that is not in this style. Hence I can understand why people may object to changing their style. However, this is the very reason why a common style is beneficial. You can get used to a new style and once you do, the entire project will be styled in the way that you are used to. Providing the style is sensible, I would much rather use a style consistent across the projects I work on. I'm happy for that style to be different to my current style. > As I stated above JBossAS mandates a style at build time. I don't particularly like the style (braces should occupy their own line, IMO) but I'm happy to go with this one if it becomes the Narayana standard style. > I think we should also break the build for violations. This should prevent mistakes making their way into SVN. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 7 13:58:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 7 Feb 2017 13:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-989) Consider using a common code style throughout Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360015#comment-13360015 ] Ondra Chaloupka commented on JBTM-989: -------------------------------------- I do understand, I will get used to the current style of work just my humble opinion * no coding style could be painful for newcomers who wants to contribute (like me) * it's harder to read the code as each class is formatted differently * it's harder to maintain code as you need to switch from style to style when switching classes > Consider using a common code style throughout Narayana > ------------------------------------------------------ > > Key: JBTM-989 > URL: https://issues.jboss.org/browse/JBTM-989 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 4.17.0.M1/5.0.0.M1 > Reporter: Paul Robinson > Assignee: Tom Jenkinson > > I think we should consider using a common code style throughout the TS project. The benefits of doing this are as follows: > # You can automate code formatting. This is a real productivity boost as you can type away, thinking about your code, rather than the style. When you hit save, or trigger it directly, the code is formatted. > ## This is not possible without a project wide code style as you too frequently re-format code that needs to stay in someone else's personal style. You can't commit this changed code as; a) it may annoy the "owner" and b) it results in a change that can't be diffed (every line may be changed). > # We get consistency over the whole project, making it easier to read code written by others. > # We have to do this anyway for code we maintain inside the JBossAS project as the project refuses to build if it doesn't adhere to their style. > Personally, I like the style I've used for the last 10 years. I find it harder to read code that is not in this style. Hence I can understand why people may object to changing their style. However, this is the very reason why a common style is beneficial. You can get used to a new style and once you do, the entire project will be styled in the way that you are used to. Providing the style is sensible, I would much rather use a style consistent across the projects I work on. I'm happy for that style to be different to my current style. > As I stated above JBossAS mandates a style at build time. I don't particularly like the style (braces should occupy their own line, IMO) but I'm happy to go with this one if it becomes the Narayana standard style. > I think we should also break the build for violations. This should prevent mistakes making their way into SVN. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 8 05:22:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 8 Feb 2017 05:22:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2847) Static code analysis - check report and fix issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2847: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done The mentioned issues taken from static code analysis report were addressed. > Static code analysis - check report and fix issues > -------------------------------------------------- > > Key: JBTM-2847 > URL: https://issues.jboss.org/browse/JBTM-2847 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 5.5.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > By going through static code analysis report of changes done during last a half year there are few issues that would be fine to be adjusted. > They are following > # at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, > L614; com.arjuna.ats.internal.jta.transaction.jts.jca, L471 > (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L614) the calling method getCurrentTransactionId() potentially could end with > NullPointerException (caused by TransactionImple#getTransaction when `final BasicAction current = BasicAction.Current()` is null) > # possible resource leak - connection was ommitted to be closed > ## org.jboss.narayana.tomcat.jta.integration.TestExecutor > ## TestCommitMarkableResourceFailAfterCommitOrphan > # inner class SampleLockable of org.jboss.stm.STMVerticle could be static (http://station5.brq.redhat.com:8080/docs/en/findbugs/fb_checker_ref.html#FB.SIC_INNER_SHOULD_BE_STATIC) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 14 12:21:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 14 Feb 2017 12:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: David Lloyd created JBTM-2848: --------------------------------- Summary: Transaction .equals() methods do not comply with specification Key: JBTM-2848 URL: https://issues.jboss.org/browse/JBTM-2848 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Reporter: David Lloyd Priority: Blocker The JTA specification has this to say about Transaction.equals(): {quote} The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. {code} Transaction txObj = TransactionManager.getTransaction(); Transaction someOtherTxObj = .. .. boolean isSame = txObj.equals(someOtherTxObj); {code} In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. {quote} There are several transaction implementation classes in Narayana including: * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 14 12:36:00 2017 From: issues at jboss.org (Anonymous (JIRA)) Date: Tue, 14 Feb 2017 12:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when David M. Lloyd created pull request #1127 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 14 12:53:00 2017 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 14 Feb 2017 12:53:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan reassigned JBTM-2848: -------------------------------- Assignee: Ondra Chaloupka > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 05:49:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 05:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363723#comment-13363723 ] Tom Jenkinson commented on JBTM-2848: ------------------------------------- Hi [~dmlloyd] - this is by intention. The subordinate types are not intended to be equal to the root coordinator types because you can't do the same types of operation on both. For example, a key difference between the two is the implementation of commit: https://github.com/dmlloyd/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java#L113 If all you need is some way to access the UID to test for same global transaction ID we can move https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/jta/transaction/Transaction.java#L69 or https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/jta/transaction/Transaction.java#L67 to the SPI? > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 06:51:01 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 15 Feb 2017 06:51:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363781#comment-13363781 ] David Lloyd commented on JBTM-2848: ----------------------------------- The JTA specification seems pretty clear on the point. Also in terms of best practices, whether or not you can do the same operations doesn't typically have any bearing on the equals/hashCode contract, generally speaking, so already it's a pretty unusual case, the more so because hashCode does not discriminate by type; it's hard to imagine any correctness issue that this behavior actually solves. If a user needs to discriminate based purely on behavior or available operations, they would naturally examine the type themselves using any number of common idioms as they would for any other type. >From the container code perspective, I probably can adjust to assume that the implementation doesn't actually conform to specification in some places but as long as Narayana is returning different types in different situations for the same XID, at some point this is going to cause an issue because I've relied on this aspect of the specification for quite a long time. If the importer always returns the same type for a given XID then that's probably enough to conform to the specification (barring the case where someone manually manufactures an invalid TransactionImple) and also makes my problem go away; I just went for the solution that I see as more practical, correct, and idiomatic. > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 06:57:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 06:57:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363792#comment-13363792 ] Tom Jenkinson commented on JBTM-2848: ------------------------------------- Let's see how CI goes. I do take your point about equality based on both referring to the same global transaction. > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 07:02:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 07:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363801#comment-13363801 ] Tom Jenkinson commented on JBTM-2848: ------------------------------------- I would say though that this behaviour has existing in Narayana since it was imported into svn at Red Hat 11 years ago. > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 07:41:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 15 Feb 2017 07:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned JBTM-2848: --------------------------------- Assignee: David Lloyd (was: Ondra Chaloupka) > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 07:41:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 15 Feb 2017 07:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned JBTM-2848: --------------------------------- Assignee: Tom Jenkinson (was: David Lloyd) > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Tom Jenkinson > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 07:42:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 15 Feb 2017 07:42:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363838#comment-13363838 ] David Lloyd commented on JBTM-2848: ----------------------------------- I would say it's not the only 10+ year old bug in our code base :) > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Tom Jenkinson > Priority: Blocker > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 08:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 08:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2848: -------------------------------- Fix Version/s: 5.next > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 08:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 08:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2848: ----------------------------------- Assignee: David Lloyd (was: Tom Jenkinson) > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 5.next > > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 08:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 08:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2848: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 5.next > > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:00:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:00:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2843) BlackTie builds failing (including release quickstarts) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2843: -------------------------------- Fix Version/s: 5.next > BlackTie builds failing (including release quickstarts) > ------------------------------------------------------- > > Key: JBTM-2843 > URL: https://issues.jboss.org/browse/JBTM-2843 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > There are some builds failing consistently: > Main build: > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/58/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux/console > Hanging here: > {quote} > jboss.naming.context.java.JmsXA: javax.naming.NameNotFoundException: JmsXA -- service jboss.naming.context.java.JmsXA > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.codehaus.stomp.jms.StompConnect.createXAConnectionFactory(StompConnect.java:195) > at org.codehaus.stomp.jms.StompConnect.getXAConnectionFactory(StompConnect.java:84) > at org.codehaus.stomp.jms.StompConnect.assignProtocolConverter(StompConnect.java:64) > at org.codehaus.stomp.tcp.TcpTransportServer.run(TcpTransportServer.java:82) > at java.lang.Thread.run(Thread.java:745) > {quote} > Release quickstarts: > http://narayanaci1.eng.hst.ams2.redhat.com/job/release-narayana-quickstarts/13/console > (similar error and shows > {quote} > [exec] "Services that were unable to start:" => ["jboss.concurrent.ee.context.service.default"], > [exec] "Services that may be the cause:" => [ > [exec] "jboss.iiop-openjdk.naming-service", > [exec] "jboss.iiop-openjdk.orb-service" > {quote} > ) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2848. ------------------------------- > Transaction .equals() methods do not comply with specification > -------------------------------------------------------------- > > Key: JBTM-2848 > URL: https://issues.jboss.org/browse/JBTM-2848 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 5.5.2.Final > > > The JTA specification has this to say about Transaction.equals(): > {quote} > The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction. > For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method. > {code} > Transaction txObj = TransactionManager.getTransaction(); > Transaction someOtherTxObj = .. > .. > boolean isSame = txObj.equals(someOtherTxObj); > {code} > In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal. > {quote} > There are several transaction implementation classes in Narayana including: > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}} > * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}} > Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail. > I'll provide a PR that fixes the issue which you can use if you want. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2847) Static code analysis - check report and fix issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2847. ------------------------------- > Static code analysis - check report and fix issues > -------------------------------------------------- > > Key: JBTM-2847 > URL: https://issues.jboss.org/browse/JBTM-2847 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 5.5.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.5.2.Final > > > By going through static code analysis report of changes done during last a half year there are few issues that would be fine to be adjusted. > They are following > # at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, > L614; com.arjuna.ats.internal.jta.transaction.jts.jca, L471 > (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L614) the calling method getCurrentTransactionId() potentially could end with > NullPointerException (caused by TransactionImple#getTransaction when `final BasicAction current = BasicAction.Current()` is null) > # possible resource leak - connection was ommitted to be closed > ## org.jboss.narayana.tomcat.jta.integration.TestExecutor > ## TestCommitMarkableResourceFailAfterCommitOrphan > # inner class SampleLockable of org.jboss.stm.STMVerticle could be static (http://station5.brq.redhat.com:8080/docs/en/findbugs/fb_checker_ref.html#FB.SIC_INNER_SHOULD_BE_STATIC) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2844) Compensations EAR archive test fails on JDK9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2844. ------------------------------- > Compensations EAR archive test fails on JDK9 > -------------------------------------------- > > Key: JBTM-2844 > URL: https://issues.jboss.org/browse/JBTM-2844 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.5.2.Final > > > EarArchiveTestLocal test fails with the following error: > {code} > javax.xml.ws.WebServiceException: java.nio.file.FileSystemNotFoundException > at org.jboss.narayana.compensations.integration.archive.EarArchiveTestLocal.(EarArchiveTestLocal.java:44) > Caused by: java.nio.file.FileSystemNotFoundException > at org.jboss.narayana.compensations.integration.archive.EarArchiveTestLocal.(EarArchiveTestLocal.java:44) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2838) Please give back IPv6 profile for raw-xts-api-demo quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2838. ------------------------------- > Please give back IPv6 profile for raw-xts-api-demo quickstart > ------------------------------------------------------------- > > Key: JBTM-2838 > URL: https://issues.jboss.org/browse/JBTM-2838 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.0.Final > Reporter: Daniel Simko > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.5.2.Final > > > This profile was removed by https://github.com/jbosstm/quickstart/commit/033d521bc78d80cedb36d1d085635edea6df303f#diff-150d8375c28d69d9eb53270d79389a41L275 > and our IPv6 tests are failing because of that. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2843) BlackTie builds failing (including release quickstarts) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2843. ------------------------------- > BlackTie builds failing (including release quickstarts) > ------------------------------------------------------- > > Key: JBTM-2843 > URL: https://issues.jboss.org/browse/JBTM-2843 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.5.2.Final > > > There are some builds failing consistently: > Main build: > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/58/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux/console > Hanging here: > {quote} > jboss.naming.context.java.JmsXA: javax.naming.NameNotFoundException: JmsXA -- service jboss.naming.context.java.JmsXA > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.codehaus.stomp.jms.StompConnect.createXAConnectionFactory(StompConnect.java:195) > at org.codehaus.stomp.jms.StompConnect.getXAConnectionFactory(StompConnect.java:84) > at org.codehaus.stomp.jms.StompConnect.assignProtocolConverter(StompConnect.java:64) > at org.codehaus.stomp.tcp.TcpTransportServer.run(TcpTransportServer.java:82) > at java.lang.Thread.run(Thread.java:745) > {quote} > Release quickstarts: > http://narayanaci1.eng.hst.ams2.redhat.com/job/release-narayana-quickstarts/13/console > (similar error and shows > {quote} > [exec] "Services that were unable to start:" => ["jboss.concurrent.ee.context.service.default"], > [exec] "Services that may be the cause:" => [ > [exec] "jboss.iiop-openjdk.naming-service", > [exec] "jboss.iiop-openjdk.orb-service" > {quote} > ) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2833: -------------------------------- Fix Version/s: 5.next (was: 5.5.2.Final) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2831: -------------------------------- Fix Version/s: 5.next (was: 5.5.2.Final) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.5.2.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:02:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2542: -------------------------------- Fix Version/s: 5.next (was: 5.5.2.Final) > Migrate performance tests to the performance repo > ------------------------------------------------- > > Key: JBTM-2542 > URL: https://issues.jboss.org/browse/JBTM-2542 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > Attachments: config.xml, eap-cmp-config.xml > > > We still have lots of performance related unit tests that need migrating: > rts/at/tx/src/test/java/org/jboss/jbossts/star/test/PerformanceTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/commitmarkable/PerformanceTestCommitMarkableResource.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance1.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance2.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance4.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance1.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance2.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/PerfHammer.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/GridWorker.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/local/synchronizations/Performance.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/Product.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/ProductWorker.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:04:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2838) Please give back IPv6 profile for raw-xts-api-demo quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2838: --------------------------------- > Please give back IPv6 profile for raw-xts-api-demo quickstart > ------------------------------------------------------------- > > Key: JBTM-2838 > URL: https://issues.jboss.org/browse/JBTM-2838 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.0.Final > Reporter: Daniel Simko > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.5.2.Final > > > This profile was removed by https://github.com/jbosstm/quickstart/commit/033d521bc78d80cedb36d1d085635edea6df303f#diff-150d8375c28d69d9eb53270d79389a41L275 > and our IPv6 tests are failing because of that. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:04:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2838) Please give back IPv6 profile for raw-xts-api-demo quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2838: -------------------------------- Issue Type: Bug (was: Enhancement) > Please give back IPv6 profile for raw-xts-api-demo quickstart > ------------------------------------------------------------- > > Key: JBTM-2838 > URL: https://issues.jboss.org/browse/JBTM-2838 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.5.0.Final > Reporter: Daniel Simko > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.5.2.Final > > > This profile was removed by https://github.com/jbosstm/quickstart/commit/033d521bc78d80cedb36d1d085635edea6df303f#diff-150d8375c28d69d9eb53270d79389a41L275 > and our IPv6 tests are failing because of that. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 15 09:04:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 15 Feb 2017 09:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2838) Please give back IPv6 profile for raw-xts-api-demo quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2838. ------------------------------- Resolution: Done > Please give back IPv6 profile for raw-xts-api-demo quickstart > ------------------------------------------------------------- > > Key: JBTM-2838 > URL: https://issues.jboss.org/browse/JBTM-2838 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.5.0.Final > Reporter: Daniel Simko > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.5.2.Final > > > This profile was removed by https://github.com/jbosstm/quickstart/commit/033d521bc78d80cedb36d1d085635edea6df303f#diff-150d8375c28d69d9eb53270d79389a41L275 > and our IPv6 tests are failing because of that. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 17 10:19:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 17 Feb 2017 10:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2849) Correct typo in docs regarding versions of the spec XTS supports In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2849: ----------------------------------- Summary: Correct typo in docs regarding versions of the spec XTS supports Key: JBTM-2849 URL: https://issues.jboss.org/browse/JBTM-2849 Project: JBoss Transaction Manager Issue Type: Bug Components: Documentation Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Minor Fix For: 5.next XTS supports 1.1 and 1.2, not 1.0: https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 17 10:19:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 17 Feb 2017 10:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2849) Correct typo in docs regarding versions of the spec XTS supports In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #44 in GitHub ------------------------------------------------------------------------------------------ Status: Pull Request Sent (was: Open) > Correct typo in docs regarding versions of the spec XTS supports > ---------------------------------------------------------------- > > Key: JBTM-2849 > URL: https://issues.jboss.org/browse/JBTM-2849 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > XTS supports 1.1 and 1.2, not 1.0: > https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 17 10:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 17 Feb 2017 10:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2849) Correct typo in docs regarding versions of the spec XTS supports In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2849: -------------------------------- Description: XTS implements 1.1 and 1.2, not 1.0: https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml was: XTS supports 1.1 and 1.2, not 1.0: https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml > Correct typo in docs regarding versions of the spec XTS supports > ---------------------------------------------------------------- > > Key: JBTM-2849 > URL: https://issues.jboss.org/browse/JBTM-2849 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > XTS implements 1.1 and 1.2, not 1.0: > https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 06:58:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 20 Feb 2017 06:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2849) Correct typo in docs regarding versions of the spec XTS supports In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2849: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Correct typo in docs regarding versions of the spec XTS supports > ---------------------------------------------------------------- > > Key: JBTM-2849 > URL: https://issues.jboss.org/browse/JBTM-2849 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > XTS implements 1.1 and 1.2, not 1.0: > https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 10:10:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 20 Feb 2017 10:10:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1132 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 02:56:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 02:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) [GSS](7.1.0) XA resource with same RMid are not ended properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson moved JBEAP-8981 to JBTM-2850: -------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2850 (was: JBEAP-8981) Issue Type: Task (was: Bug) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JTA (was: EJB) (was: Transactions) Steps to Reproduce: (was: Please find attached reproducer.zip Steps to Reproduce: 1) Deploy the 2 wars (project 1 and project 2) in the same Jboss server. 2) Run the GUI client (mvn exec:java in sources files folder) Actual results: following logs shows that "end" method is only called on XAResource 1. 09:18:34,564 INFO { } [stdout] (EJB default - 1) start resource2 xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac129ea0:6ee503a4:5864c6a7:11, node_name=1, branch_uid=0:ffffac129ea0:6ee503a4:5864c6a7:17, subordinatenodename=null, eis_name=unknown eis name > 09:18:34,565 INFO { } [stdout] (EJB default - 1) end resource1 xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac129ea0:6ee503a4:5864c6a7:11, node_name=1, branch_uid=0:ffffac129ea0:6ee503a4:5864c6a7:17, subordinatenodename=null, eis_name=unknown eis name > 09:18:34,565 INFO { } [stdout] (EJB default - 1) prepare resource1 xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac129ea0:6ee503a4:5864c6a7:11, node_name=1, branch_uid=0:ffffac129ea0:6ee503a4:5864c6a7:17, subordinatenodename=null, eis_name=unknown eis name > 09:18:34,574 INFO { } [stdout] (EJB default - 1) commit resource1 xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac129ea0:6ee503a4:5864c6a7:11, node_name=1, branch_uid=0:ffffac129ea0:6ee503a4:5864c6a7:17, subordinatenodename=null, eis_name=unknown eis name >) Affects Version/s: (was: 7.0.z.GA) Fix Version/s: 5.next (was: 7.1.0.GA) > [GSS](7.1.0) XA resource with same RMid are not ended properly > -------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Amit Nijhawan > Assignee: David Lloyd > Fix For: 5.next > > > A scenario with a EJB XA transaction between two applications (war). The process is the following: > 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. > 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction > 3. the project 2 enlist two XA resources that share the same RMid. > 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. > The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA/XA specifications. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 02:56:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 02:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) [GSS](7.1.0) XA resource with same RMid are not ended properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Description: A scenario with a EJB XA transaction between two applications (war). The process is the following: 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction 3. the project 2 enlist two XA resources that share the same RMid. 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. was: A scenario with a EJB XA transaction between two applications (war). The process is the following: 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction 3. the project 2 enlist two XA resources that share the same RMid. 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA/XA specifications. > [GSS](7.1.0) XA resource with same RMid are not ended properly > -------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Amit Nijhawan > Assignee: David Lloyd > Fix For: 5.next > > > A scenario with a EJB XA transaction between two applications (war). The process is the following: > 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. > 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction > 3. the project 2 enlist two XA resources that share the same RMid. > 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. > The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 02:56:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 02:56:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Enable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Summary: Enable (was: [GSS](7.1.0) XA resource with same RMid are not ended properly) > Enable > ------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Amit Nijhawan > Assignee: David Lloyd > Fix For: 5.next > > > A scenario with a EJB XA transaction between two applications (war). The process is the following: > 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. > 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction > 3. the project 2 enlist two XA resources that share the same RMid. > 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. > The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 02:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 02:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Enable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Reporter: Tom Jenkinson (was: Amit Nijhawan) > Enable > ------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: David Lloyd > Fix For: 5.next > > > A scenario with a EJB XA transaction between two applications (war). The process is the following: > 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. > 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction > 3. the project 2 enlist two XA resources that share the same RMid. > 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. > The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 02:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 02:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Enable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2850: ----------------------------------- Assignee: Tom Jenkinson (was: David Lloyd) > Enable > ------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > A scenario with a EJB XA transaction between two applications (war). The process is the following: > 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. > 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction > 3. the project 2 enlist two XA resources that share the same RMid. > 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. > The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 02:58:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 02:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Summary: Call xa_end on duplicate XAResource as per JTA 1.2 specification (was: Enable ) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > A scenario with a EJB XA transaction between two applications (war). The process is the following: > 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. > 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction > 3. the project 2 enlist two XA resources that share the same RMid. > 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. > The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 03:06:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 03:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Description: JTA 1.2 changed requirement: "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** What is happening at the moment for two difference instance of an XAR but where isSameRM is true: Resource1 start TMNOFLAGS DuplicateResource1 start TMJOIN Resource2 start TMNOFLAGS Resource1 end TMSUCCESS Resource1 prepare Resource2 end TMSUCCESS Resource2 prepare Resource1 commit Resource2 commit Post https://java.net/jira/browse/JTA_SPEC-3 this should be: Resource1 start TMNOFLAGS DuplicateResource1 start TMJOIN Resource2 start TMNOFLAGS Resource1 end TMSUCCESS DuplicateResource1 end TMSUCCESS Resource1 prepare Resource2 end TMSUCCESS Resource2 prepare Resource1 commit Resource2 commit was: A scenario with a EJB XA transaction between two applications (war). The process is the following: 1. a client GUI is calling a remote EJB on project 1 that initiate the XA transaction. 2. The project 1 call a remote EJB on project 2 that create a new branch in XA transaction 3. the project 2 enlist two XA resources that share the same RMid. 4. EJB call on both project 2 and project 1 and 2PC is initiated by project 1 to commit the XA transaction. The expected behaviour is that "start" and "end" operations are called on both XA resource enlisted in project 2 as mentioned in JTA 1.2 specifications. > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 03:06:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 03:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Issue Type: Enhancement (was: Task) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 03:07:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 03:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366648#comment-13366648 ] Tom Jenkinson commented on JBTM-2850: ------------------------------------- This can likely be addressed somewhere around: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L1327 However it will also need addressing in all the other TransactionImple types (JTS, subordinate) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 03:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 03:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2851: ----------------------------------- Summary: Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) Key: JBTM-2851 URL: https://issues.jboss.org/browse/JBTM-2851 Project: JBoss Transaction Manager Issue Type: Task Components: BlackTie Reporter: Tom Jenkinson Assignee: Amos Feng Fix For: 5.next -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 03:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Feb 2017 03:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Parent: JBTM-2685 Issue Type: Sub-task (was: Task) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 02:40:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 22 Feb 2017 02:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2851: ---------------------------- Description: The blacktie-admin-service-ear will failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html [2] https://github.com/jboss/openjdk-orb/pull/4 > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear will failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 02:40:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 22 Feb 2017 02:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2851: ---------------------------- Description: The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html [2] https://github.com/jboss/openjdk-orb/pull/4 was: The blacktie-admin-service-ear will failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html [2] https://github.com/jboss/openjdk-orb/pull/4 > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 15:09:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 22 Feb 2017 15:09:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2852) Transaction integration failures with CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka moved JBEAP-9047 to JBTM-2852: ---------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2852 (was: JBEAP-9047) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JTA (was: Transactions) Affects Version/s: 5.5.2.Final (was: 7.1.0.DR12) > Transaction integration failures with CDI > ----------------------------------------- > > Key: JBTM-2852 > URL: https://issues.jboss.org/browse/JBTM-2852 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > There are failures in integration of transaction and cdi because of introducing of new wildfly transaction client. > The new client does not verify transaction availability where JTA-CDI requires IllegalStateException. > Related test case could be > https://github.com/scottmarlow/wildfly/commit/34385c25a2b0126eafe791914ef8ea5feda25d3c -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 15:13:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 22 Feb 2017 15:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2853: ------------------------------------- Summary: Transaction bridging for WS not working because of switch to new wfly transaction client Key: JBTM-2853 URL: https://issues.jboss.org/browse/JBTM-2853 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Blocker Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 15:14:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 22 Feb 2017 15:14:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2853: ------------------------------------- Assignee: Ondra Chaloupka > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 15:15:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 22 Feb 2017 15:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2853: ---------------------------------- Affects Version/s: 5.5.2.Final > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 15:15:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 22 Feb 2017 15:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2853: ---------------------------------- Component/s: TxBridge > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 00:50:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 23 Feb 2017 00:50:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: David Lloyd created JBTM-2854: --------------------------------- Summary: XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException Key: JBTM-2854 URL: https://issues.jboss.org/browse/JBTM-2854 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Reporter: David Lloyd Priority: Blocker Here is what the stack trace looks like: {noformat} Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) ... 11 more {noformat} It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 04:16:00 2017 From: issues at jboss.org (Anonymous (JIRA)) Date: Thu, 23 Feb 2017 04:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when chalda created pull request #19 in GitHub ----------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 04:16:00 2017 From: issues at jboss.org (Anonymous (JIRA)) Date: Thu, 23 Feb 2017 04:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2852) Transaction integration failures with CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when chalda created pull request #19 in GitHub ----------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Transaction integration failures with CDI > ----------------------------------------- > > Key: JBTM-2852 > URL: https://issues.jboss.org/browse/JBTM-2852 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > There are failures in integration of transaction and cdi because of introducing of new wildfly transaction client. > The new client does not verify transaction availability where JTA-CDI requires IllegalStateException. > Related test case could be > https://github.com/scottmarlow/wildfly/commit/34385c25a2b0126eafe791914ef8ea5feda25d3c -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 04:52:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 04:52:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2854: ----------------------------------- Assignee: Michael Musgrove > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Blocker > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 04:53:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 04:53:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2846: ----------------------------------- Assignee: Michael Musgrove > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 05:00:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 23 Feb 2017 05:00:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367969#comment-13367969 ] Michael Musgrove commented on JBTM-2846: ---------------------------------------- [~dmlloyd] Do you have a test case that shows up the issue - I ask because this is code that has been running for 20+ years without issues in this area? > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 05:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 05:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2854: -------------------------------- Priority: Critical (was: Blocker) > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 05:30:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 05:30:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367993#comment-13367993 ] Tom Jenkinson commented on JBTM-2854: ------------------------------------- Hi [~dmlloyd] - we do need that bit of data as this is the way we can check during recovery (with shared object store) if the Xid belongs to the calling server and whether it was orphaned: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/jca/SubordinateAtomicAction.java#L115 https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L416 https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java#L50 It's encoded in the bqual: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XATxConverter.java#L198 > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 05:39:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 05:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2854: -------------------------------- Priority: Major (was: Critical) > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 06:21:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 06:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368035#comment-13368035 ] Tom Jenkinson commented on JBTM-2854: ------------------------------------- There is a critical issue here but it's rather in the way WFTC is not attempting to pass in the full Xid. The reason I downgraded the JBTM to Major is that you have to pass us more data in the Xid than the gtrid so even making a better error message it would be for something that should not happen. You have to pass us the Xid of the parent SubordinateTransaction for importing of the propagated transaction so that when you call doRecover with the parent node name we can give you the right set of transactions back. You could think of the interface for importing transactions as: importTransaction(byte[] gtrid, String parent) The parent name for importing is part of the Xid in the propagator node and can be determined before propagation using: ((com.arjuna.ats.jta.transaction.Transactio) transactionManagerService.getTransactionManager().getTransaction()).getTxId(); // The Javadoc is not clear, for subordinate transactions data is included in the Xid beyond the gtrid Note that passing a dummy bqual with zerod data would not fully work because of the reason that we wouldn't be able to record the correct parent node name. This would mean in a recovery situation the parent would need to be sure to directly scan all known servers - reducing the opportunity to clean up partially completed transactions to when the root coordinator was online. That might well work but it wasn't designed that way and so lots of tests will fail (and the slower recovery I just mentioned). Recovery for EJB remoting was designed to go A -> B -> C rather than A -> C. > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 06:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 06:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368046#comment-13368046 ] Tom Jenkinson commented on JBTM-2846: ------------------------------------- [~mmusgrov]: you could create a test with byteman. What you would need to do is Thread1: 1. call tx::setRollbackOnly 2. allow https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java#L262 3. Hold https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java#L263 Thread2: 5. call tx::rollback 6. allow https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java#L1685 Thread 1: 7. allow https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java#L263 Thread2: 8. https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java#L1694 will now return ActionStatus.ABORT_ONLY 9. observe this is not done: https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/TwoPhaseCoordinator.java#L127 > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 06:46:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 06:46:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368055#comment-13368055 ] Tom Jenkinson commented on JBTM-2846: ------------------------------------- save_state - it seems susceptible to the same issue with preventCommit (assuming a very long delay between check and set) restore_state - OK as its just called by recovery manager on new instances toString - syncing for that operation seems wasteful > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 08:42:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 23 Feb 2017 08:42:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368159#comment-13368159 ] David Lloyd commented on JBTM-2846: ----------------------------------- I observed one possibly sporadic test failure that could possibly have been explained by this or a different problem. As for 20+ years, well, the memory model itself is 12 years old (before then the rules were quite different), and every Java release is a bit more aggressively efficient than the last in terms of exploiting the properties of the JMM for performance gains. But, I think the fix could probably be as simple as throwing a "volatile" on there. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 08:44:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 23 Feb 2017 08:44:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368161#comment-13368161 ] David Lloyd commented on JBTM-2846: ----------------------------------- The reason I didn't include it is logical: we use test cases to find problems. But in this case, I've already found the problem. I don't need a test case to prove that it is a problem because the JMM proves it for me; it's a problem whether or not it's likely to be observed. And the way this logic runs, the more you consider unobservable problems to be non-problems, the more you're stacking the deck for a quite dark day. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 08:59:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 23 Feb 2017 08:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368172#comment-13368172 ] David Lloyd commented on JBTM-2854: ----------------------------------- OK in that case I agree to lower the priority and I'll ensure that the subordinate is importing the bqual. I had thought the parent name was encoded in the gtid, but that was just an unwarranted assumption on my part. > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 09:50:02 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Feb 2017 09:50:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368233#comment-13368233 ] Tom Jenkinson commented on JBTM-2854: ------------------------------------- The root parent name is in the gtrid, but a subordinate parent name is in the bqual (cos we can't edit the gtrid). Thanks! > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Michael Musgrove > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 10:52:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 23 Feb 2017 10:52:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2855) Consider using assertions to validate locking assumptions In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2855: -------------------------------------- Summary: Consider using assertions to validate locking assumptions Key: JBTM-2855 URL: https://issues.jboss.org/browse/JBTM-2855 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Transaction Core Affects Versions: 5.5.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Fix For: 5.later Some methods in BasicAction assume that other methods will acquire monitors before calling them; it would aid both maintenance/readability and testing if we such methods have assert Thread.holdsLock(this); at their beginning point. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 10:56:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 23 Feb 2017 10:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1134 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 11:47:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 23 Feb 2017 11:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2856) Add a way to register an interposed synchronization without associating the txn In-Reply-To: References: Message-ID: David Lloyd created JBTM-2856: --------------------------------- Summary: Add a way to register an interposed synchronization without associating the txn Key: JBTM-2856 URL: https://issues.jboss.org/browse/JBTM-2856 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Application Server Integration Reporter: David Lloyd Assignee: Amos Feng It would be very useful to the application server if there were an API method to register an interposed synchronization on a transaction that was not currently associated with the calling thread, the same way that non-interposed synchronizations can be. Right now the only two options are to use TransactionSynchronizationRegistry, which requires that the existing transaction be suspended and a new one associated, or to use reflection to directly call the registerSynchronizationImple method of the transaction. Neither one is optimal. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 12:54:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 23 Feb 2017 12:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2854: -------------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > Assignee: Tom Jenkinson > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 14:02:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 23 Feb 2017 14:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368454#comment-13368454 ] David Lloyd commented on JBTM-2846: ----------------------------------- OK I have good news and bad news. Bad news first: there's a real (non-theoretical) thread safety problem that may crop up under load which is not solved solely by setting {{volatile}}. It happens under the described circumstances, where setRollbackOnly() can return successfully yet prepare() or commit(true) also succeeds. The good news is I worked up a quick patch for it: https://github.com/jbosstm/narayana/compare/master...dmlloyd:jbtm-2846 If it looks OK I can put it in as a PR. I tried to explain the logic in the comments so hopefully it's clear why it's needed and why it works. But I can't test it locally through the Narayana test suite at the moment due to other things I have going on, so it's up to you guys what you want to do. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 24 07:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 24 Feb 2017 07:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1135 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 24 11:37:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 24 Feb 2017 11:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369118#comment-13369118 ] Michael Musgrove commented on JBTM-2846: ---------------------------------------- I do not see how the scenario you suggest can occur if we protect the update of actionStatus in BasicAction#preventCommit is protected by the instance monitor: synchronized (this) { if (actionStatus == ActionStatus.RUNNING) actionStatus = ActionStatus.ABORT_ONLY; } > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 24 16:41:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 24 Feb 2017 16:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2857) Investigate XTS outbound bridge potential nullpointer issue In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2857: ------------------------------------- Summary: Investigate XTS outbound bridge potential nullpointer issue Key: JBTM-2857 URL: https://issues.jboss.org/browse/JBTM-2857 Project: JBoss Transaction Manager Issue Type: Task Components: XTS Affects Versions: 5.5.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor During working on JBTM-2853 it was found `NullPointer` could be potentially thrown from `OutboundBridgeManager` when `getTransaction()` returns `null`. It's at time when thread is not associated with any txn. Discussion about this at PR: https://github.com/jbosstm/narayana/pull/1133 ``` Transaction transaction = (Transaction)TransactionManager.transactionManager().getTransaction(); ``` https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/org/jboss/jbossts/txbridge/outbound/OutboundBridgeManager.java#L69 Goal is to investigate this potential exception being trouble or not and if such thing could happen or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Feb 25 15:59:00 2017 From: issues at jboss.org (David Lloyd (JIRA)) Date: Sat, 25 Feb 2017 15:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369324#comment-13369324 ] David Lloyd commented on JBTM-2846: ----------------------------------- You are right, but with this approach a different problem occurs. The lock which is held during state changes would prevent setRollbackOnly from working during subordinate synchronization execution. This is an example of why synchronization should generally protect data, not code. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 05:58:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 05:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369510#comment-13369510 ] Tom Jenkinson commented on JBTM-2846: ------------------------------------- actionStatus is kind of data. I don't think it would deadlock, it might hold it up if the TX is already in the process of completing but that wouldn't be undesirable either. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 05:59:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 05:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2846: -------------------------------- Fix Version/s: 5.next > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 05:59:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 05:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2846: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 07:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 07:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2858: ----------------------------------- Summary: Transaction bridging for WS not working because of switch to new wfly transaction client Key: JBTM-2858 URL: https://issues.jboss.org/browse/JBTM-2858 Project: JBoss Transaction Manager Issue Type: Bug Components: TxBridge Affects Versions: 5.5.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Blocker Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 07:21:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 07:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2858: -------------------------------- Summary: Transaction bridging for REST-AT not working because of switch to new wfly transaction client (was: Transaction bridging for WS not working because of switch to new wfly transaction client) > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 07:21:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 07:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2858: -------------------------------- Description: Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. was: Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 07:22:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 07:22:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2858: -------------------------------- Component/s: REST (was: TxBridge) > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 08:42:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 08:42:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2859) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2859: ----------------------------------- Summary: Transaction bridging for REST-AT not working because of switch to new wfly transaction client Key: JBTM-2859 URL: https://issues.jboss.org/browse/JBTM-2859 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.5.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Blocker Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 09:00:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 27 Feb 2017 09:00:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #21 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 09:47:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 27 Feb 2017 09:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2852) Transaction integration failures with CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2852: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Transaction integration failures with CDI > ----------------------------------------- > > Key: JBTM-2852 > URL: https://issues.jboss.org/browse/JBTM-2852 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > There are failures in integration of transaction and cdi because of introducing of new wildfly transaction client. > The new client does not verify transaction availability where JTA-CDI requires IllegalStateException. > Related test case could be > https://github.com/scottmarlow/wildfly/commit/34385c25a2b0126eafe791914ef8ea5feda25d3c -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:34:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:34:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2853: -------------------------------- Fix Version/s: 5.next > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.next > > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2859) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson deleted JBTM-2859: -------------------------------- > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2859 > URL: https://issues.jboss.org/browse/JBTM-2859 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2858: -------------------------------- Fix Version/s: 5.next > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.next > > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2852) Transaction integration failures with CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2852: -------------------------------- Fix Version/s: 5.next > Transaction integration failures with CDI > ----------------------------------------- > > Key: JBTM-2852 > URL: https://issues.jboss.org/browse/JBTM-2852 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.next > > > There are failures in integration of transaction and cdi because of introducing of new wildfly transaction client. > The new client does not verify transaction availability where JTA-CDI requires IllegalStateException. > Related test case could be > https://github.com/scottmarlow/wildfly/commit/34385c25a2b0126eafe791914ef8ea5feda25d3c -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2852) Transaction integration failures with CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2852. ------------------------------- > Transaction integration failures with CDI > ----------------------------------------- > > Key: JBTM-2852 > URL: https://issues.jboss.org/browse/JBTM-2852 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.5.3.Final > > > There are failures in integration of transaction and cdi because of introducing of new wildfly transaction client. > The new client does not verify transaction availability where JTA-CDI requires IllegalStateException. > Related test case could be > https://github.com/scottmarlow/wildfly/commit/34385c25a2b0126eafe791914ef8ea5feda25d3c -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2849) Correct typo in docs regarding versions of the spec XTS supports In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2849. ------------------------------- > Correct typo in docs regarding versions of the spec XTS supports > ---------------------------------------------------------------- > > Key: JBTM-2849 > URL: https://issues.jboss.org/browse/JBTM-2849 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.5.3.Final > > > XTS implements 1.1 and 1.2, not 1.0: > https://github.com/jbosstm/documentation/edit/master/product/en-US/txbridge_guide/introduction.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2846. ------------------------------- > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.5.3.Final > > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2858: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.next > > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2853: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.next > > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b65e8c75fc > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2850: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2831: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2833: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2542: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Migrate performance tests to the performance repo > ------------------------------------------------- > > Key: JBTM-2542 > URL: https://issues.jboss.org/browse/JBTM-2542 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > Attachments: config.xml, eap-cmp-config.xml > > > We still have lots of performance related unit tests that need migrating: > rts/at/tx/src/test/java/org/jboss/jbossts/star/test/PerformanceTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/commitmarkable/PerformanceTestCommitMarkableResource.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance1.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance2.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance4.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance1.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance2.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/PerfHammer.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/GridWorker.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/local/synchronizations/Performance.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/Product.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/ProductWorker.java -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 27 10:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 27 Feb 2017 10:40:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 28 00:56:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 28 Feb 2017 00:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2860) Add new event types for authorization checking In-Reply-To: References: Message-ID: Amos Feng created JBTM-2860: ------------------------------- Summary: Add new event types for authorization checking Key: JBTM-2860 URL: https://issues.jboss.org/browse/JBTM-2860 Project: JBoss Transaction Manager Issue Type: Enhancement Components: SPI Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 28 01:21:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 28 Feb 2017 01:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2861) Introduce the authorization checking In-Reply-To: References: Message-ID: Amos Feng created JBTM-2861: ------------------------------- Summary: Introduce the authorization checking Key: JBTM-2861 URL: https://issues.jboss.org/browse/JBTM-2861 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTS Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 28 10:00:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 28 Feb 2017 10:00:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2862) Check places where trace logs are not conditional, especially see xts bridge In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2862: ------------------------------------- Summary: Check places where trace logs are not conditional, especially see xts bridge Key: JBTM-2862 URL: https://issues.jboss.org/browse/JBTM-2862 Project: JBoss Transaction Manager Issue Type: Enhancement Components: XTS Affects Versions: 5.5.3.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor During an investigation on JBTM-2853 and JBTM-2858 was discovered there are places where {{txbridgeLogger.logger.trace}} is used without conditional check if trace logging is enabled or not as it's good practice in other parts of the code. It should be checked where the conditional trace logging misses and fix those places. A hot candidate is XTS but there could be other places in code base too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)