February 2017 - jbossts-issues - Jboss List Archives

[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.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)

7 years, 2 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.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/ma... > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.... ] 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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2843) BlackTie builds failing (including release quickstarts)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2843?page=com.atlassian.jira.plugin.... ] 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=BLACKT... > 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-quickstar... > (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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2838) Please give back IPv6 profile for raw-xts-api-demo quickstart

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2838?page=com.atlassian.jira.plugin.... ] 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/033d521bc78d80cedb36d1d08563... > and our IPv6 tests are failing because of that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2844) Compensations EAR archive test fails on JDK9

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2844?page=com.atlassian.jira.plugin.... ] 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.<init>(EarArchiveTestLocal.java:44) > Caused by: java.nio.file.FileSystemNotFoundException > at org.jboss.narayana.compensations.integration.archive.EarArchiveTestLocal.<init>(EarArchiveTestLocal.java:44) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2847) Static code analysis - check report and fix issues

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2847?page=com.atlassian.jira.plugin.... ] 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...) 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#...) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ] 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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2843) BlackTie builds failing (including release quickstarts)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2843?page=com.atlassian.jira.plugin.... ] 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=BLACKT... > 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-quickstar... > (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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ] 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)

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2017