March 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send()

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.5.4.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/c035f66960d18...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2831: -------------------------------- Fix Version/s: 5.next (was: 5.5.4.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/ma... > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2858. ------------------------------- > 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.5.4.Final > > > 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/5eb816e0b58da3e99bfee81715ba27b... > 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2858: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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/5eb816e0b58da3e99bfee81715ba27b... > 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2853: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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/5eb816e0b58da3e99bfee81715ba27b... > 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2850: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2542: -------------------------------- Fix Version/s: 5.later (was: 5.next) > 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.later > > 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2822: ------------------------------------- local JTA only - not supported on JTS due to CosTransactions.idl > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.1.Final > > > JBTM-2636 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2120) Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2120?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2120: ------------------------------------- local JTA only - not supported on JTS due to CosTransactions.idl > Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2120 > URL: https://issues.jboss.org/browse/JBTM-2120 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.2.6.Final > > > Pull https://github.com/jbosstm/narayana/pull/598 added deferred throwables in case the XAR::end fails during commit. It doesn't handle the case of the HEURISTIC_ROLLBACK of a first resource where Narayana rolls back the remaining participants and then clears the failed/heuristic lists (and marks the txn as rolled back). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2850: ------------------------------------- If we received multiple errors we will add them as suppressed exceptions, however we will only be able to return these for JTA mode because JTS IDL does not allow for sending the suppressed exceptions from the server side back to the caller. > 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)

7 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2017