January 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2428. ------------------------------- Resolution: Migrated to another ITS > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-tra... > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-tra... > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-tra... > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2759) Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2759?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2759. ------------------------------- > Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2759 > URL: https://issues.jboss.org/browse/JBTM-2759 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.3.5.Final > > > _CID-17577_: Bad choice of lock object - Potential lock collisions > at class {{BaseTransactionManagerDelegate}}[9] at method {{findLock}}. > {quote} > string_literal: The string literal "__LOCKS_MAP" is an interned string. > interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > Instead of using "__LOCKS_MAP" as a lock, create a final field of type Object which is only used as a lock. > {quote} > Explanation at description of JBTM-2758 > [9] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/integration/src... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2758) Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2758?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2758. ------------------------------- > Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2758 > URL: https://issues.jboss.org/browse/JBTM-2758 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.3.5.Final > > > _CID-17581_: Bad choice of lock object - Potential lock collisions > at class `FileProcessId`[6] method `getpid` with error message > {quote} > Interned string as a lock may cause deadlocks or performance problems if a library also uses the interned string as a lock. > string_literal: The string literal "0x" is an interned string. > interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > Instead of using "0x" as a lock, create a final field of type Object which is only used as a lock. > {quote} > See Java examples at Coverity page [7]. The explanation there is that > String literals are centrally interned and could also be locked on by a > library, causing you to potentially have deadlocks or lock collisions > with other code. > There are several places [8] on net when searching for `java synchronzation on strings`. > [6] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes... > [7] https://ondemand.coverity.com/reference/7.6.1/en/coverity#N5069A > [8] http://www.javalobby.org/java/forums/t96352.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2701. ------------------------------- > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.2.21.Final, 5.3.5.Final > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1957) XTS crash recovery tests fail on IBM JDK

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1957?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1957. ------------------------------- Resolution: Done > XTS crash recovery tests fail on IBM JDK > ---------------------------------------- > > Key: JBTM-1957 > URL: https://issues.jboss.org/browse/JBTM-1957 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 4.17.10 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.0.0.CR2 > > > The XTS crash recovery tests fail on IBM JDK. This seem to be a problem of Arquillian settings. > What I do: > - switch to IBM JDK (JAVA_HOME + PATH) > - export JBOSS_HOME=/home/ochaloup/jboss/jboss-eap-* > - cd XTS/localjunit/crash-recovery-tests > - mvn test -Pxts.integration.tests.profile -Parq -Dtest=com.arjuna.qa.junit.TestATCrashDuringOnePhaseCommit > What I get - tests fail with error: > The server is already running! Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server. Please stop server before running or change to another type of container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2845) REST-AT bridge recovery test hanging because of missing client api

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2845?page=com.atlassian.jira.plugin.... ] Work on JBTM-2845 started by Gytis Trikleris. --------------------------------------------- > REST-AT bridge recovery test hanging because of missing client api > ------------------------------------------------------------------ > > Key: JBTM-2845 > URL: https://issues.jboss.org/browse/JBTM-2845 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > REST-AT bridge recovery test is hanging in all environments. > It seems that the cause is a change in WildFly modules. Following errors appears in a test log: > {code} > c (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] > ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:103) > ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newClient(ClientBuilder.java:114) > ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:239) > ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202) > ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153) > ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62) > ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105) > ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.<init>(InboundBridgeManager.java:60) > ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50) > ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.addBridgesToMapping(InboundBridgeRecoveryModule.java:164) > ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.periodicWorkSecondPass(InboundBridgeRecoveryModule.java:109) > ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder from [Module "javax.ws.rs.api" from local module loader @a87f8ec (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] > ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:200) > ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) > ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) > ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName0(Native Method) > ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName(Class.java:264) > ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.newInstance(FactoryFinder.java:113) > ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.find(FactoryFinder.java:206) > ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:86) > ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) ... 12 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1957) XTS crash recovery tests fail on IBM JDK

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1957?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-1957: --------------------------------- > XTS crash recovery tests fail on IBM JDK > ---------------------------------------- > > Key: JBTM-1957 > URL: https://issues.jboss.org/browse/JBTM-1957 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 4.17.10 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.0.0.CR2 > > > The XTS crash recovery tests fail on IBM JDK. This seem to be a problem of Arquillian settings. > What I do: > - switch to IBM JDK (JAVA_HOME + PATH) > - export JBOSS_HOME=/home/ochaloup/jboss/jboss-eap-* > - cd XTS/localjunit/crash-recovery-tests > - mvn test -Pxts.integration.tests.profile -Parq -Dtest=com.arjuna.qa.junit.TestATCrashDuringOnePhaseCommit > What I get - tests fail with error: > The server is already running! Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server. Please stop server before running or change to another type of container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1957) XTS crash recovery tests fail on IBM JDK

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1957?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1957: -------------------------------- Fix Version/s: 5.0.0.CR2 > XTS crash recovery tests fail on IBM JDK > ---------------------------------------- > > Key: JBTM-1957 > URL: https://issues.jboss.org/browse/JBTM-1957 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 4.17.10 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.0.0.CR2 > > > The XTS crash recovery tests fail on IBM JDK. This seem to be a problem of Arquillian settings. > What I do: > - switch to IBM JDK (JAVA_HOME + PATH) > - export JBOSS_HOME=/home/ochaloup/jboss/jboss-eap-* > - cd XTS/localjunit/crash-recovery-tests > - mvn test -Pxts.integration.tests.profile -Parq -Dtest=com.arjuna.qa.junit.TestATCrashDuringOnePhaseCommit > What I get - tests fail with error: > The server is already running! Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server. Please stop server before running or change to another type of container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2845) REST-AT bridge recovery test hanging because of missing client api

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-2845: ------------------------------------- Summary: REST-AT bridge recovery test hanging because of missing client api Key: JBTM-2845 URL: https://issues.jboss.org/browse/JBTM-2845 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Blocker Fix For: 5.next REST-AT bridge recovery test is hanging in all environments. It seems that the cause is a change in WildFly modules. Following errors appears in a test log: {code} c (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:103) ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newClient(ClientBuilder.java:114) ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:239) ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202) ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153) ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62) ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105) ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.<init>(InboundBridgeManager.java:60) ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50) ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.addBridgesToMapping(InboundBridgeRecoveryModule.java:164) ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.periodicWorkSecondPass(InboundBridgeRecoveryModule.java:109) ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder from [Module "javax.ws.rs.api" from local module loader @a87f8ec (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:200) ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName0(Native Method) ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName(Class.java:264) ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.newInstance(FactoryFinder.java:113) ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.find(FactoryFinder.java:206) ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:86) ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) ... 12 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2736) Enhance error log message on long node name to contain max node name length

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2736?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2736: -------------------------------- Fix Version/s: 5.3.5.Final > Enhance error log message on long node name to contain max node name length > --------------------------------------------------------------------------- > > Key: JBTM-2736 > URL: https://issues.jboss.org/browse/JBTM-2736 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.3.5.Final > > > When maximal node identifier size is exceeded an exception and log message is shown. This message does not contain information what was the maximum of the node identifier length for user could easily adjust his setting based on that info. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 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 January 2017