April 2008 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-357) add open source DTF tests

by Jonathan Halliday (JIRA)

add open source DTF tests ------------------------- Key: JBTM-357 URL: http://jira.jboss.com/jira/browse/JBTM-357 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.3.0.GA Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.4.CR1 As the DTF is now open source, we should open source the DTF tests for JBossTS (i.e. jbossts-qa) and add it to the JBossTS code repository -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-331) Reduce the log level of the periodic recovery stuff

by David Lloyd (JIRA)

Reduce the log level of the periodic recovery stuff --------------------------------------------------- Key: JBTM-331 URL: http://jira.jboss.com/jira/browse/JBTM-331 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Recovery Reporter: David Lloyd The JBossAS log (as of 5.0.0.Beta4) is filled with this kind of thing: 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - second pass <Thu, 28 Feb 2008 17:57:51> 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass 2008-02-28 17:59:51,703 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <Thu, 28 Feb 2008 17:59:51> 2008-02-28 17:59:51,704 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass 2008-02-28 17:59:51,704 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass 2008-02-28 17:59:51,704 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass These messages ought to be at TRACE level. The first hint is that this is the only thing spamming the log after successful startup. Also on more than one occasion, folks pop into the public #jboss IRC channel asking about why their logs get spammed with these messages. An otherwise idle JBossAS instance quietly gobbles 750kb of disk space a day with these messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
8
0 / 0

[JBoss JIRA] Created: (JBTM-304) Update the management MBean with all of the collected statistics

by Mark Little (JIRA)

Update the management MBean with all of the collected statistics ---------------------------------------------------------------- Key: JBTM-304 URL: http://jira.jboss.com/jira/browse/JBTM-304 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tooling Reporter: Mark Little Assigned To: Andrew Dinn Priority: Minor JBossTS collects more information than the MBean now exposes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBTM-354) race condition in XAResource start/end handling due to async rollback

by Jonathan Halliday (JIRA)

race condition in XAResource start/end handling due to async rollback --------------------------------------------------------------------- Key: JBTM-354 URL: http://jira.jboss.com/jira/browse/JBTM-354 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.3.0.GA, 4.2.3.SP5 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP8, 4.4.CR1 There exists a race condition such that we may call start on an XAResource but never call end (or anything else) on it if the transaction times out whilst the resource enlistment is still in progress. This is a Bad Thing and may make resource managers unhappy. To reproduce: TransactionManager tm = new TransactionManagerImple(); tm.setTransactionTimeout(5); tm.begin(); Transaction t = tm.getTransaction(); // XAResourceImpl has a start method with Thread.sleep longer than 5s XAResource xaResource = new XAResourceImpl(); t.enlistResource(xaResource); Thread.sleep(10); // reaper times out the tx, resource manager for XAResource // *may* have received start but never receives end. Fix notes: TransactionImple.enlistResource needs to lock out the reaper thread. At first glance an alternative fix is to put the resource into the transaction's internal data structure before calling start on it, but that would allow an 'end, begin' sequence of calls to be seen by the resource manager. caution: ref support case i-t #171373 there *may* exist additional race conditions in the app server JCA so this change alone won't necessarily fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-289) remove use of Synchronizations for lock storage in jboss integration

by Jonathan Halliday (JIRA)

remove use of Synchronizations for lock storage in jboss integration -------------------------------------------------------------------- Key: JBTM-289 URL: http://jira.jboss.com/jira/browse/JBTM-289 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP6 JBossAS needs to be able to lock transactions regardless of their state. Since the current integration implementation uses Synchronizations to store lock state, locking is possible only during transactions lifecycle phases where Synchronization registration is permitted. Relax this by changing the integration so that locks are stored using the general object storage mechanism added to TransactionImple to support JTA 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
6
0 / 0

[JBoss JIRA] Created: (JBTM-319) Update JNDI recovery to cope with WrappedDataSource

by Mark Little (JIRA)

Update JNDI recovery to cope with WrappedDataSource --------------------------------------------------- Key: JBTM-319 URL: http://jira.jboss.com/jira/browse/JBTM-319 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation, Recovery Affects Versions: 4.2.3.SP6 Reporter: Mark Little -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

3
13
0 / 0

[JBoss JIRA] Created: (JBTM-279) Find the JBossMQ recovery code and make sure it's shipped in the next release of AS.

by Mark Little (JIRA)

Find the JBossMQ recovery code and make sure it's shipped in the next release of AS. ------------------------------------------------------------------------------------ Key: JBTM-279 URL: http://jira.jboss.com/jira/browse/JBTM-279 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Jonathan Halliday Priority: Blocker Adrian did some work on providing a ResourceRecovery implementation and RecoveryModule for JBossMQ (for Glencore). I had assumed that support would make sure it was shipped in subsequent releases of AS (since recovery is pretty important), but that doesn't seem to be the case. If they are not going to do it, then we need to because MQ is effectively frozen (at least that's what Adrian thought). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

4
8
0 / 0

[JBoss JIRA] Created: (JBTM-338) Slow shutdown of the transaction service

by Dimitris Andreadis (JIRA)

Slow shutdown of the transaction service ---------------------------------------- Key: JBTM-338 URL: http://jira.jboss.com/jira/browse/JBTM-338 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.3.0.BETA2 Reporter: Dimitris Andreadis Priority: Critical Fix For: 4.3.0.BETA3 I'm looking in the jboss testsuite, at a group of tests that starts a custom jboss config (jacc) and spotted this failed attempt to stop the server within 45secs. http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test... ... [server:stop] Shutting down server: jacc [server:stop] Shutting down server: /qa/tools/opt/jdk1.5.0_12/bin/java -cp /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR1/bin/shutdown.jar:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR1/client/jbossall-client.jar:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR1/client/jboss-common.jar org.jboss.Shutdown --server jnp://10.18.96.175:1099 --shutdown [server:stop] shutdownTimeout will be=45 [server:stop] Failed to shutdown server "jacc" before timeout. Destroying the process. ... By digging further in the server.log you can see that most of the shutdown sequence is completed within 1 second, but then almost a minute after the last logged message (58secs) the arjuna periodic recovery thread is still active (see below) and this causes the testsuite to kill the process. JBossTS seems to not shutdown properly / in-time. 2008-03-04 04:38:43,432 DEBUG [org.jboss.resource.connectionmanager.ManagedConnectionFactoryDeployment] Stopped jboss.jca:service=ManagedConnectionFactory,name=JmsXA 2008-03-04 04:38:43,433 DEBUG [org.jboss.jms.server.ServerPeer] Stopping jboss.messaging:service=ServerPeer 2008-03-04 04:38:43,433 INFO [org.jboss.jms.server.ServerPeer] ServerPeer[0] is Stopping. NOTE! Stopping the server peer cleanly will NOT cause failover to occur 2008-03-04 04:39:41,452 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <Tue, 4 Mar 2008 04:39:41> 2008-03-04 04:39:41,453 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass 2008-03-04 04:39:41,453 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass 2008-03-04 04:39:41,454 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass 2008-03-04 04:39:51,454 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - second pass <Tue, 4 Mar 2008 04:39:51> 2008-03-04 04:39:51,454 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass 2008-03-04 04:39:51,454 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass 2008-03-04 04:39:51,454 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass 2008-03-04 04:41:51,457 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <Tue, 4 Mar 2008 04:41:51> 2008-03-04 04:41:51,457 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass 2008-03-04 04:41:51,458 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass 2008-03-04 04:41:51,458 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass 2008-03-04 04:42:01,460 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - second pass <Tue, 4 Mar 2008 04:42:01> 2008-03-04 04:42:01,460 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass 2008-03-04 04:42:01,460 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass 2008-03-04 04:42:01,460 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

6
12
0 / 0

[JBoss JIRA] Created: (JBTM-355) Be able to configure transport timeout in com.arjuna.webservices.util.TransportTimer from some configuration file

by Pavel Kadlec (JIRA)

Be able to configure transport timeout in com.arjuna.webservices.util.TransportTimer from some configuration file ----------------------------------------------------------------------------------------------------------------- Key: JBTM-355 URL: http://jira.jboss.com/jira/browse/JBTM-355 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: WS-T Implementation Reporter: Pavel Kadlec The timeout in com.arjuna.webservices.util.TransportTimer is fixed and as far as I know there is not possible to configure it from configuration file. 30 seconds (default value) is too short for my purposes, I have large transaction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

3
7
0 / 0

[JBoss JIRA] Closed: (JBTM-37) Modifications for the OASIS WS-TX Standard

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-37?page=all ] Andrew Dinn closed JBTM-37. --------------------------- Resolution: Done closed with correct fix version > Modifications for the OASIS WS-TX Standard > ------------------------------------------ > > Key: JBTM-37 > URL: http://jira.jboss.com/jira/browse/JBTM-37 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.4.CR1 > > > Preliminary support for the OASIS WS-TX standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2008