[JBoss JIRA] (JBTM-1426) ORA-01000: maximum open cursors exceeded during oracle JDBC object store test
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1426?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1426:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ORA-01000: maximum open cursors exceeded during oracle JDBC object store test
> -----------------------------------------------------------------------------
>
> Key: JBTM-1426
> URL: https://issues.jboss.org/browse/JBTM-1426
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, Transaction Core
> Reporter: Gytis Trikleris
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M2
>
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> See: http://172.17.131.2/job/jbossts-EAP61-jdbcobjectstore/31
> {noformat}
> starting command: /usr/local/jdk1.6.0_37/bin/java -classpath dist/narayana-full-4.17.4.Final-SNAPSHOT/etc/:dist/narayana-full-4.17.4.Final-SNAPSHOT/lib/*:dist/narayana-full-4.17.4.Final-SNAPSHOT/lib/ext/*:dist/narayana-full-4.17.4.Final-SNAPSHOT/jacorb/lib/*:dist/narayana-full-4.17.4.Final-SNAPSHOT/jacorb/etc/:ext/fscontext.jar:ext/providerutil.jar:ext/jboss-profiler-jvmti.jar:ext/jboss-logging-spi.jar:tests/build/classes/:dbdrivers/selected_dbdriver/*:dbdrivers/DB2_v9.7/db2jcc.jar:dbdrivers/jConnect-6_0/classes/jconn3.jar:dbdrivers/mssql2005_sqljdbc_2.0/enu/sqljdbc4.jar:dbdrivers/mysql-connector-java-5.1.8-bin.jar:dbdrivers/oracle_10_2_0_4/ojdbc14.jar:dbdrivers/postgresql-8.3-605.jdbc4.jar:../build/extlib/emma.jar:../build/extlib/netty.jar -Dqa.debug=true -Djava.naming.provider.url=file:///tmp -Djava.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory -Dperformanceprofilestore.dir=config/perf_profiles/ -Djdbcprofilestore.dir=config/jdbc_profiles -Dmemorytestprofilestore.dir=config/memory_profiles/ -Dots.server.bindname=value_1 -DCoordinatorEnvironmentBean.maintainHeuristics=NO -DRecoveryEnvironmentBean.recoveryBackoffPeriod=5 -DCoreEnvironmentBean.timeoutFactor=2 -DCoordinatorEnvironmentBean.defaultTimeout=240 -Demma.coverage.out.file=./testoutput/txcore_lockrecord/LockRecord_Thread_Test028b/client_0-coverage.ec -DportOffsetId=1 -DObjectStoreBaseDir=/home/hudson/workspace/jbossts-EAP61-jdbcobjectstore/qa/testoutput/txcore_lockrecord/LockRecord_Thread_Test028b/client_0 -DRecoveryEnvironmentBean.recoveryListener=true -DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=oracle.jdbc.pool.OracleDataSource;DriverType=thin;ServerName=tywin.buildnet.ncl.jboss.com;NetworkProtocol=tcp;DatabaseName=orcl;PortNumber=1521;User=dtf11;Password=dtf11 -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=oracle.jdbc.pool.OracleDataSource;DriverType=thin;ServerName=tywin.buildnet.ncl.jboss.com;NetworkProtocol=tcp;DatabaseName=orcl;PortNumber=1521;User=dtf11;Password=dtf11 -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=oracle.jdbc.pool.OracleDataSource;DriverType=thin;ServerName=tywin.buildnet.ncl.jboss.com;NetworkProtocol=tcp;DatabaseName=orcl;PortNumber=1521;User=dtf11;Password=dtf11 -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication org.jboss.jbossts.qa.ArjunaCore.LockManager.client.WorkerClient003 -newlock 10 10 2
> 2013-01-11 06:42:48,696 err: log4j:WARN No appenders could be found for logger (org.jboss.logging).
> 2013-01-11 06:42:48,696 err: log4j:WARN Please initialize the log4j system properly.
> 2013-01-11 06:42:49,683 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,700 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,703 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,705 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,707 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,709 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,711 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,717 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,719 err: trying to get lock for 1000th time
> 2013-01-11 06:42:49,721 err: trying to get lock for 1000th time
> 2013-01-11 06:42:52,690 out: 2013-01-11 06:42:52,689 [Thread-1] WARN com.arjuna.ats.arjuna - ARJUNA012258: JDBCImple:write_state caught exception
> 2013-01-11 06:42:52,691 out: java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
> 2013-01-11 06:42:52,691 out: ORA-01000: maximum open cursors exceeded
> 2013-01-11 06:42:52,691 out: ORA-00604: error occurred at recursive SQL level 1
> 2013-01-11 06:42:52,691 out: ORA-01000: maximum open cursors exceeded
> 2013-01-11 06:42:52,691 out: ORA-01000: maximum open cursors exceeded
> 2013-01-11 06:42:52,691 out:
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:970)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3370)
> 2013-01-11 06:42:52,691 out: at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3454)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver.commit_state(JDBCImple_driver.java:104)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.commit_state(JDBCStore.java:124)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.internal.arjuna.abstractrecords.PersistenceRecord.topLevelCommit(PersistenceRecord.java:171)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2733)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2649)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1814)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1505)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 2013-01-11 06:42:52,691 out: at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:147)
> 2013-01-11 06:42:52,691 out: at org.jboss.jbossts.qa.ArjunaCore.LockManager.client.Worker003.run(Worker003.java:65)
> ....
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1211) Fix qa suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1211?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1211:
---------------------------------------
http://172.17.131.2/job/narayana/148
> Fix qa suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote
> ------------------------------------------------------------------------------
>
> Key: JBTM-1211
> URL: https://issues.jboss.org/browse/JBTM-1211
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS, Testing, Transaction Core
> Affects Versions: 4.16.4
> Reporter: Paul Robinson
> Assignee: Michael Musgrove
> Fix For: 4.17.4, 5.0.0.M2
>
> Attachments: jbossts-narayana-java6-ipv6-dualstack.57.tar, jtsremote(1).zip, jtsremote.zip
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> See: http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-branch416-java6/232
> {code}
> Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote
> [junit] Tests run: 9, Failures: 1, Errors: 0, Time elapsed: 169.235 sec
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris logged work on JBTM-1356:
-----------------------------------------
Author: Gytis Trikleris
Created on: 18/Jan/13 11:24 AM
Start Date: 18/Jan/13 7:00 AM
Worklog Time Spent: 1 hour
Issue Time Tracking
-------------------
Time Spent: 6 hours (was: 5 hours)
Worklog Id: (was: 12428419)
> Parallel prepare implementation does not handle LRCO correctly
> --------------------------------------------------------------
>
> Key: JBTM-1356
> URL: https://issues.jboss.org/browse/JBTM-1356
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.M1
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Optional
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit.
> The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1356:
----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
> Parallel prepare implementation does not handle LRCO correctly
> --------------------------------------------------------------
>
> Key: JBTM-1356
> URL: https://issues.jboss.org/browse/JBTM-1356
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.M1
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Optional
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 5 hours
> Remaining Estimate: 0 minutes
>
> We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit.
> The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1429) Document the PartcipantCompletion race condition
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1429?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1429:
--------------------------------
Remaining Estimate: 1 day, 4 hours (was: 2 days, 4 hours)
> Document the PartcipantCompletion race condition
> ------------------------------------------------
>
> Key: JBTM-1429
> URL: https://issues.jboss.org/browse/JBTM-1429
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Documentation, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M2
>
> Original Estimate: 3 days
> Time Spent: 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> * Add logging to WARN when it happens
> * Add explanation of why and when it happens to XTS docs and how to spot if you have it
> * Blog about it
> * Link to the docs in the quickstart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1429) Document the PartcipantCompletion race condition
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1429?page=com.atlassian.jira.plugin.... ]
Paul Robinson logged work on JBTM-1429:
---------------------------------------
Author: Paul Robinson
Created on: 18/Jan/13 6:57 AM
Start Date: 18/Jan/13 6:56 AM
Worklog Time Spent: 4 hours
Issue Time Tracking
-------------------
Remaining Estimate: 2 days, 4 hours (was: 3 days)
Time Spent: 4 hours
Worklog Id: (was: 12428418)
> Document the PartcipantCompletion race condition
> ------------------------------------------------
>
> Key: JBTM-1429
> URL: https://issues.jboss.org/browse/JBTM-1429
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Documentation, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M2
>
> Original Estimate: 3 days
> Time Spent: 4 hours
> Remaining Estimate: 2 days, 4 hours
>
> * Add logging to WARN when it happens
> * Add explanation of why and when it happens to XTS docs and how to spot if you have it
> * Blog about it
> * Link to the docs in the quickstart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1356 started by Gytis Trikleris.
> Parallel prepare implementation does not handle LRCO correctly
> --------------------------------------------------------------
>
> Key: JBTM-1356
> URL: https://issues.jboss.org/browse/JBTM-1356
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.M1
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Optional
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 5 hours
> Remaining Estimate: 0 minutes
>
> We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit.
> The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1424) Remove static block from org.jboss.jbossts.xts.environment.XTSPropertyManager
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1424?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris logged work on JBTM-1424:
-----------------------------------------
Author: Gytis Trikleris
Created on: 18/Jan/13 6:48 AM
Start Date: 18/Jan/13 6:30 AM
Worklog Time Spent: 10 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 10 minutes)
Time Spent: 10 minutes
Worklog Id: (was: 12428417)
> Remove static block from org.jboss.jbossts.xts.environment.XTSPropertyManager
> -----------------------------------------------------------------------------
>
> Key: JBTM-1424
> URL: https://issues.jboss.org/browse/JBTM-1424
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Original Estimate: 10 minutes
> Time Spent: 10 minutes
> Remaining Estimate: 0 minutes
>
> Where it catches an exception in the static block and then just uses system properties. I would say that behavior would be better encapsulated in XTSPropertiesFactory.getDefaultProperties itself (thereby removing another static block and making XTSPropertiesFactory.getDefaultProperties more stable).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months