March 2008 - jbossts-issues - Jboss List Archives

[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

16 years, 6 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, 7 months

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, 7 months

6
12
0 / 0

[JBoss JIRA] Created: (JBTM-350) tx.registerSynchronization does not throw RollbackException as per JTA 1.1 page 36

by Carlo de Wolf (JIRA)

tx.registerSynchronization does not throw RollbackException as per JTA 1.1 page 36 ---------------------------------------------------------------------------------- Key: JBTM-350 URL: http://jira.jboss.com/jira/browse/JBTM-350 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Carlo de Wolf Priority: Critical 18:39:56,203 WARN [SessionSynchronizationInterceptor] Unexpected IllegalStateException for tx TransactionImple < ac, BasicAction: 7f000101:e23d:47e2a121:6f status: ActionStatus.ABORT_ONLY > with status 1 After tm.setRollbackOnly the transaction is in STATUS_MARKED_ROLLBACK, but tx.registerSynchronization throws an IllegalStateException instead of RollbackException. -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-348) decouple TransactionStatusManager from SocketProcessId

by Jonathan Halliday (JIRA)

decouple TransactionStatusManager from SocketProcessId ------------------------------------------------------ Key: JBTM-348 URL: http://jira.jboss.com/jira/browse/JBTM-348 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.3.0.GA Reporter: Jonathan Halliday Assigned To: Michael Musgrove Fix For: 4.4.CR1 The TransactionStatusManager resuses the ServerSocket opened by SocketProcessId, in an effort to reduce the overall number of ports in use by the system. SocketProcessId needs the socket only to guarantee it's uniq, it does not actually move traffic over it. TransactionStatusManager uses it to handle queries regarding the status of in-flight transactions. The problems start when the box has multiple IP addresses. SocketProcessId must bind on a fixed IP (probably 127.0.0.1) common to all JBossTS instances on the machine, in order that the port number remains uniq across all running JVMs. The TransactionStatusManager however must bind on a user specified IP in order that multiple instances may run on the same machine without interference. Thus it is not appropriate for TransactionStatusManager to reuse the SocketProcessId's ServerSocket. Decouple these, such that TransactionStatusManager reads its config properties and opens a ServerSocket directly, whilst SocketProcessId reads a different config property for its port number rather than reusing the TSM's config property. -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-253) Listen address of JBossTS ports not configurable

by Arto Huusko (JIRA)

Listen address of JBossTS ports not configurable ------------------------------------------------ Key: JBTM-253 URL: http://jira.jboss.com/jira/browse/JBTM-253 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.2.3.SP3 Environment: JBoss AS 4.2.0 GA Reporter: Arto Huusko Assigned To: Mark Little JBossTS integrated in JBoss AS 4.2.0 GA always binds some tcp ports to listen on all addresses. jboss.bind.address has no effect on the listen address, nor is it otherwise configurable. Looking at source code (for example ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/TransactionStatusManager.java in jbossts-jta-4.2.3.SP3-src.zip) confirms that there is no kind of support for binding the listen address, only the port can be freely selected. The listen address should be configurable, so that it can be limited to localhost, for example. In addition, if possible, it would be nice to be able to disable listening on any ports. I'm not sure if the TransactionStatusManager really needs to listen on any port in a simple JBoss AS installation. -- 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, 7 months

4
10
0 / 0

[JBoss JIRA] Created: (JBTM-324) Enable Setting Port with com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort

by Thomas Krieger (JIRA)

Enable Setting Port with com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort ------------------------------------------------------------------------------------ Key: JBTM-324 URL: http://jira.jboss.com/jira/browse/JBTM-324 Project: JBoss Transaction Manager Issue Type: Patch Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.2.3.SP5 Reporter: Thomas Krieger If you set <property name="com.arjuna.ats.internal.arjuna.recovery.recoveryPort" value="1213"/> <property name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="1214"/> you get the following Exception: com.arjuna.ats.arjuna.exceptions.FatalError: [com.arjuna.ats.internal.arjuna.utils.SocketProcessId_2] - SocketProcessId.getpid could not get unique port. at com.arjuna.ats.internal.arjuna.utils.SocketProcessId.getpid(SocketProcessId.java:122) at com.arjuna.ats.arjuna.utils.Utility.getpid(Utility.java:206) at com.arjuna.ats.arjuna.common.Uid.<init>(Uid.java:105) at com.arjuna.ats.arjuna.utils.Utility.getProcessUid(Utility.java:218) at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.<init>(TransactionStatusManagerItem.java:323) at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.createAndSave(TransactionStatusManagerItem.java:71) at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.start(TransactionStatusManager.java:157) at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.<init>(TransactionStatusManager.java:78) at com.arjuna.ats.arjuna.coordinator.TxControl.<clinit>(TxControl.java:312) at com.arjuna.ats.jbossatx.jta.TransactionManagerService.startService(TransactionManagerService.java:139) The first problem is that in TransactionStatusManager calling ServerSocket socket = SocketProcessId.getSocket(); returns null, so that a new ServerSocket is created in TransactionStatusManager getTsmServerSocket (int port) (line 218) The solution is, to call (new SocketProcessId()).getpid(); in the constructor. The second problem is that RecoveryManagerImple.activeRecoveryManager uses the wrong port (line 197): SocketProcessId uses Property com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort and not com.arjuna.ats.internal.arjuna.recovery.recoveryPort. Solution is to change activeRecoveryManager (). Thomas Krieger for P&I Team Tess (Ralph-Rainer Welzel, Andreas Rugullies ...) -- 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, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-352) Memory leak in TransactionReaper._timeouts

by Ivan Szanto (JIRA)

Memory leak in TransactionReaper._timeouts ------------------------------------------ Key: JBTM-352 URL: http://jira.jboss.com/jira/browse/JBTM-352 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.3.0.GA Environment: Compiled 4.3.0.GA for the EAP 4.3 as JTS according to the instructions (by setting JBOSS_HOME to jboss-5.0.0.Beta4) on RHEL4. Run ~ 1500 JMS transactions in EAP 4.3 all configuration on RHEL4 to see it leaks. Used Sun jdk 1.5.0.14 Reporter: Ivan Szanto The leak can also be seen by using the debugger to check the number of entries in TransactionReaper._timeouts after a couple of transactions. It appears that the TransactionReaper.insert method uses ControlWrapper objects as keys when putting elements into the hashtable, but the TransactionReaper.remove method sometimes unsuccessfully tries to use Uid ojbects to remove them. I will post a corrected version of TransactionReaper.java. -- 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, 8 months

4
16
0 / 0

[JBoss JIRA] Created: (JBTM-349) Unfounded exception is thrown on registerSynchronization in wrong state

by Carlo de Wolf (JIRA)

Unfounded exception is thrown on registerSynchronization in wrong state ----------------------------------------------------------------------- Key: JBTM-349 URL: http://jira.jboss.com/jira/browse/JBTM-349 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Carlo de Wolf Priority: Critical java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.syncsnotallowed] [com.arjuna.ats.internal.jta.transaction.arjunacore.syncsnotallowed] Synchronizations are not allowed! at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:473) The exception message does not say why it's not allowed (tx is in wrong state) and the context in which it is occuring (the actual tx state). -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-274) JBossWorkManager converts from seconds to milliseconds

by Mark Little (JIRA)

JBossWorkManager converts from seconds to milliseconds ------------------------------------------------------ Key: JBTM-274 URL: http://jira.jboss.com/jira/browse/JBTM-274 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Priority: Critical Fix For: 4.2.3.SP6 Transaction timeouts on the work manager were assumed to be in seconds. JBossWorkManager is converting them to milliseconds before we get the timeout. We then convert them to milliseconds (under the assumption they were defined in seconds). -- 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, 8 months

2
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2008