September 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2253) Brandon CI node misconfiguration

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2253?page=com.atlassian.jira.plugin.... ] Gytis Trikleris reopened JBTM-2253: ----------------------------------- http://172.17.131.2/view/Status/job/narayana/653/PROFILE=BLACKTIE,jdk=jdk... http://172.17.131.2/view/Status/job/narayana/654/PROFILE=BLACKTIE,jdk=jdk... http://172.17.131.2/view/Status/job/narayana/655/PROFILE=BLACKTIE,jdk=jdk... http://172.17.131.2/view/Status/job/narayana/657/PROFILE=BLACKTIE,jdk=jdk... http://172.17.131.2/view/Status/job/narayana/658/PROFILE=BLACKTIE,jdk=jdk... http://172.17.131.2/view/Status/job/narayana/659/PROFILE=BLACKTIE,jdk=jdk... > Brandon CI node misconfiguration > --------------------------------- > > Key: JBTM-2253 > URL: https://issues.jboss.org/browse/JBTM-2253 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/639/PROFILE=BLACKTIE,jdk=jdk... > {code} > [0m[31m12:39:56,830 ERROR [org.codehaus.stomp.jms.ProtocolConverter] (StompConnect Transport: tcp:///127.0.0.1:44813) Connection is closed: org.codehaus.stomp.jms.ProtocolConverter@10c10e8 > [0m[31m12:39:56,831 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:44813) Caught an exception: Broken pipe: java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] > at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_51] > at java.io.FilterOutputStream.write(FilterOutputStream.java:97) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.marshal(StompMarshaller.java:83) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.onStompFrame(TcpTransport.java:80) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.sendToStomp(ProtocolConverter.java:498) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:209) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:101) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > [0mTests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 110.88 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTopic > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.162 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.server.BlackTieServerTestCase > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.248 sec > Results : > Tests in error: > AtmiBrokerEnvXMLTest.testEnv:53 » UnknownHost brandon.buildnet.ncl.jboss.com: ... > TestConnection.setUp:29 » Configuration Could not create the orb management fu... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2265) BlackTie CI test hang

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2265?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-2265. ---------------------------------- Resolution: Rejected I accidentally deleted the associated CI job. But the failure does look like a one off CI comms issue so rejecting (if it was a real issue then we will raise a new JIRA). > BlackTie CI test hang > --------------------- > > Key: JBTM-2265 > URL: https://issues.jboss.org/browse/JBTM-2265 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Amos Feng > > CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2265) BlackTie CI test hang

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2265: -------------------------------------- Summary: BlackTie CI test hang Key: JBTM-2265 URL: https://issues.jboss.org/browse/JBTM-2265 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Amos Feng CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2264: ----------------------------------- Just to add to what Tom has said, isSameRM is the required way of checking for RM equality. It's defined in the JTA specification. > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...]. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2256: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1104584|https://bugzilla.redhat.com/show_bug.cgi?id=1104584] from MODIFIED to POST > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2255: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1080035|https://bugzilla.redhat.com/show_bug.cgi?id=1080035] from MODIFIED to POST > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1133346|https://bugzilla.redhat.com/show_bug.cgi?id=1133346] from MODIFIED to POST > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2238) Tooling does not expose CMR records

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2238?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2238: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1113225|https://bugzilla.redhat.com/show_bug.cgi?id=1113225] from MODIFIED to POST > Tooling does not expose CMR records > ----------------------------------- > > Key: JBTM-2238 > URL: https://issues.jboss.org/browse/JBTM-2238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > CMR resources are not being exposed as MBeans via the (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser) tooling. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1341: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1139102|https://bugzilla.redhat.com/show_bug.cgi?id=1139102] from MODIFIED to POST > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1143947|https://bugzilla.redhat.com/show_bug.cgi?id=1143947] from MODIFIED to POST > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 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 September 2014