October 2011 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-908) update build to use AS 7.0.2

by Jonathan Halliday (JIRA)

update build to use AS 7.0.2 ---------------------------- Key: JBTM-908 URL: https://issues.jboss.org/browse/JBTM-908 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.15.3 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.15.4 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] (JBTM-913) upgrade byteman to enable jdk7 builds

by Jonathan Halliday (Created) (JIRA)

upgrade byteman to enable jdk7 builds ------------------------------------- Key: JBTM-913 URL: https://issues.jboss.org/browse/JBTM-913 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Build System, Testing Affects Versions: 5.0.0.M1, 4.15.3 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.15.4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] (JBTM-922) Run XTS crash recovry tests manually for EAP 5.1.2

by Paul Robinson (Created) (JIRA)

Run XTS crash recovry tests manually for EAP 5.1.2 -------------------------------------------------- Key: JBTM-922 URL: https://issues.jboss.org/browse/JBTM-922 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 4.6.1.CP13 We should run these tests ASAP, as they have not been ran for a while and we need to know of any issues sooner rather than later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] (JBTM-930) Run of ATSubordinateCrashDuringPrepare.MultiParticipantPrepareAndCommitTest is missing expected output

by Paul Robinson (Created) (JIRA)

Run of ATSubordinateCrashDuringPrepare.MultiParticipantPrepareAndCommitTest is missing expected output ------------------------------------------------------------------------------------------------------ Key: JBTM-930 URL: https://issues.jboss.org/browse/JBTM-930 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.6.1.CP12 Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 4.6.1.CP13 I ran script: https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_6_1_GA_C... with test: org.jboss.jbossts.xts.servicetests.test.at.subordinate.MultiParticipantPrepareAndCommitTest And the following expected output is missing from the trace log: {code} # rollback called for pseudo participant XXXXXX # rollback called for subordinate transaction XXX # rollback sent for Participant XXXXXX # rollback received for Participant XXXXXX # aborted sent for Participant XXXXXX # aborted received for Participant XXXXXX # rollback sent for Participant XXXXXX # rollback received for Participant XXXXXX # aborted sent for Participant XXXXXX # aborted received for Participant XXXXXX # rollback returned for subordinate transaction XXX # rollback completed for pseudo participant XXXXXX {code} I think the expected output shuld actually be: {code} # rollback called for pseudo-participant XXXXXX # rollback called for subordinate coordinator XXX # rollback sent for Coordinator engine XXXXXX # rollback received for Participant XXXXXX # aborted sent for Participant XXXXXX # aborted received for Coordinator engine XXXXXX # rollback sent for Coordinator engine XXXXXX # rollback received for Participant XXXXXX # aborted sent for Participant XXXXXX # aborted received for Coordinator engine XXXXXX # rollback returned for subordinate coordinator XXX # rollback completed for pseudo-participant XXXXXX {code} Either way, these lines are missing from the output. Is this still a valid run, or do we have a failure? See attached log. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
2
0 / 0

[JBoss JIRA] (JBTM-931) beforeCompletion not called in JCA when transaction doPrepare is not called

by Tom Jenkinson (Deleted) (JIRA)

[ https://issues.jboss.org/browse/JBTM-931?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson deleted JBTM-931: ------------------------------- > beforeCompletion not called in JCA when transaction doPrepare is not called > --------------------------------------------------------------------------- > > Key: JBTM-931 > URL: https://issues.jboss.org/browse/JBTM-931 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Tom Jenkinson > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-931) beforeCompletion not called in JCA when transaction doPrepare is not called

by Tom Jenkinson (Created) (JIRA)

beforeCompletion not called in JCA when transaction doPrepare is not called --------------------------------------------------------------------------- Key: JBTM-931 URL: https://issues.jboss.org/browse/JBTM-931 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tom Jenkinson Fix For: 4.15.4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-882) org.jboss.jbossts:jbossjts:jar have to use PROVIDED scope dependency on org.jboss.logging:jboss-logging-generator:jar

by Richard Opalka (JIRA)

org.jboss.jbossts:jbossjts:jar have to use PROVIDED scope dependency on org.jboss.logging:jboss-logging-generator:jar --------------------------------------------------------------------------------------------------------------------- Key: JBTM-882 URL: https://issues.jboss.org/browse/JBTM-882 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.15.3 Reporter: Richard Opalka Fix For: 4.15.x The org.jboss.jbossts:jbossjts:jar in AS7 trunk brings in the compile dependency on org.jboss.logging:jboss-logging-generator The identified dependency tree is: [INFO] | | | +- org.jboss.jbossts:jbossjts:jar:4.15.3.Final:compile [INFO] | | | | +- commons-httpclient:commons-httpclient:jar:3.1-jbossorg-1:compile [INFO] | | | | +- emma:emma:jar:2.0.5312:compile [INFO] | | | | +- emma:emma_ant:jar:2.0.5312:compile [INFO] | | | | | \- ant:ant:jar:1.6.3:compile [INFO] | | | | +- org.hornetq:hornetq-core:jar:2.2.6.Final:compile [INFO] | | | | +- tanukisoft:wrapper:jar:3.2.3:compile [INFO] | | | | +- jacorb:jacorb:jar:2.3.1jboss.patch01-brew:compile [INFO] | | | | +- jacorb:idl:jar:2.3.1jboss.patch01-brew:compile [INFO] | | | | +- org.jboss.integration:jboss-corba-ots-spi:jar:6.0.0.CR1:compile [INFO] | | | | | \- org.jboss.javaee:jboss-transaction-api:jar:1.0.1.GA:compile [INFO] | | | | +- org.jboss.jbossas:jboss-server-manager:jar:1.0.4.Final:compile [INFO] | | | | | \- org.picketbox:jboss-security-spi:jar:3.0.0.CR2:runtime [INFO] | | | | +- org.jboss.remoting:jboss-remoting:jar:2.5.3:compile [INFO] | | | | +- dom4j:dom4j:jar:1.6.1:compile [INFO] | | | | +- org.jboss.logging:jboss-logging-generator:jar:1.0.0.Beta6:compile <<<< wrong dependency scope here [INFO] | | | | \- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile [INFO] | | | +- org.jboss.jbossts:jbossjts-integration:jar:4.15.3.Final:compile -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
9
0 / 0

[JBoss JIRA] Created: (JBTM-751) Dirty transaction remains if rollback failed

by Teofilis Martisius (JIRA)

Dirty transaction remains if rollback failed -------------------------------------------- Key: JBTM-751 URL: https://jira.jboss.org/browse/JBTM-751 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Affects Versions: 4.6.1 Environment: Jboss 5.1.0GA Reporter: Teofilis Martisius Priority: Minor Hi, I noticed that in some cases when transaction rollback fails, remaining dirty transaction is left associated with the thread when it gets returned to thread pool. Same thread gets used again producing errors. I have attached a patch I have used successfully for a while in my deployment. This patch is applicable to v4.6.1GA, but I think other versions are also affected. This issue gets triggered by exception like this one: ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (WorkManager(2)-17) Could not synchronize database state with session org.hibernate.exception.LockAcquisitionException: could not update: [org.jbpm.graph.exe.Token#15022] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:105) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2453) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2335) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2635) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365) at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1475) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:657) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:243) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1045) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949) at com.mysql.jdbc.jdbc2.optional.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:874) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2435) ... 25 more When same thread gets reused later, it produces following exception: ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (WorkManager(2)-90) org.jboss.resource.adapter.jms.inflow.Jm sServerSession$DemarcationStrategyFactory@42bae587 error creating transaction demarcation javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassocia ted] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction! at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:80) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65) at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.<init>(JmsServerSession.java:560) at org.jboss.resource.adapter.jms.inflow.JmsServerSession$DemarcationStrategyFactory.getStrategy(JmsServerSession.java:295) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.createTransactionDemarcation(JmsServerSession.java:252) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:224) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) If you need any help or information, feel free to contact me. Sincerely, Teofilis Martisius -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

6
17
0 / 0

[JBoss JIRA] (JBTM-925) Update Web services in XTS interop tests to use @Addressing

by Paul Robinson (Created) (JIRA)

Update Web services in XTS interop tests to use @Addressing ----------------------------------------------------------- Key: JBTM-925 URL: https://issues.jboss.org/browse/JBTM-925 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.6.1.CP12 Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 4.6.1.CP13 JBossWS now supports the @Addressing annotation. The Web services in the interop tests need to be updated to use this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBTM-842) improve XAResource recovery scan timing

by Jonathan Halliday (JIRA)

improve XAResource recovery scan timing --------------------------------------- Key: JBTM-842 URL: https://issues.jboss.org/browse/JBTM-842 Project: JBoss Transaction Manager Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.15.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.15.1 The current XAResource recovery algorithm includes a requirement that an suspect orphan Xid appear in two recovery scans before it is eligible for rollback under presumed abort. This closes the timing window where a tx branch has been prepared for normal termination but not yet committed. It's based on the assumption that the interval between scans is long enough for any normally executing tx to proceed from prepare to commit. Where the scans occur as part of consecutive recovery passes, this is generally the case. However... There are two cases in which scans can happen in quick succession, thus nullifying the safeguard and causing the recovery system to incorrectly presume abort on a branch. The first is caused by top down recovery running in the same pass before bottom up recovery. If a tx log contains an xaresourcerecord, its instantiation may cause a recovery scan. The second and more common case is where the user has incorrectly registered two or more recovery resources for the same RM. At first glance it seems possible to add a check to prevent this misconfiguration, but in practice it's not possible to write a robust comparison method that will work with all known RMs. Thus, as it is infeasible to prevent multiple scans occurring in quick succession, it is instead necessary to change the safeguard algorithm. We should require a set interval to pass after the first sighting of an Xid before considering it eligible for presumed abort, rather than requiring a given number of scan passes. This will require modification of XARecoveryModule.xaRecovery and RecoveryXids. An additional safeguard may be created by supplementing the existing transaction log based XAResourceOrphanFilter with one based on TransactionImple.getTransaction, at least for configurations where the recovery manager is running in-process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2011