February 2008 - jbossts-issues - Jboss List Archives

[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-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

15 years, 12 months

4
8
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

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

3
5
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, 1 month

2
9
0 / 0

[JBoss JIRA] Created: (JBTM-325) Reconcile conflicting overrides of commons-logging Log4JLogger

by Brian Stansberry (JIRA)

Reconcile conflicting overrides of commons-logging Log4JLogger -------------------------------------------------------------- Key: JBTM-325 URL: http://jira.jboss.com/jira/browse/JBTM-325 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.3.0.BETA2 Reporter: Brian Stansberry As part of the fix for JBTM-20, JBossTS instructs Jakarta Commons Logging to use com.arjuna.common.internal.util.logging.jakarta.Log4JLogger as its implementation of the JCL Log interface. This supersedes an alternate override of the default JCL behavior that JBoss AS had in place. The AS is using a special forked version of JCL 1.1.0 known as 1.1.0.jboss. The fork involves changing the org.apache.commons.logging.Log4JLogger class to better support use of separate log4j subsystems between different deployments. We need to reconcile these two conflicting overrides of the default JCL behavior and make sure the goals of each are fulfilled. At the moment, I'm aware of two things the AS fork was doing that the com.arjuna version is not: 1) Support for trace level logging -- the com.arjuna class seems to be based on older code and maps trace to debug. 2) Support for not binding of org.apache.log4j classes, using the TCCL to load the log4j classes when a Log4JLogger instance is created and using reflection to invoke upon them. The AS fork isn't doing any of the i18n stuff that AIUI the JBossTS version does. The source for the AS fork of JCL can be found at: 1) https://svn.jboss.org/repos/repository.jboss.org/apache-logging/1.1.0.jbo... 2) cvs -d:ext:starksm@cvs.forge.jboss.com:/cvsroot/jboss co apache CVS tag for the 1.1.0.jboss release is JBoss_Apache_Common_Logging_1_1_0 -- 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 month

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-320) jta/jtax cross-package logging broken

by Jonathan Halliday (JIRA)

jta/jtax cross-package logging broken ------------------------------------- Key: JBTM-320 URL: http://jira.jboss.com/jira/browse/JBTM-320 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.3.0.BETA2, 4.2.3.SP6 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP8, 4.3.0.BETA3 Some classes in jtax i.e. the JTS based JTA implementation, use logging support from the jta rather than jtax pakage. This is the only instance of cross-package logging in the codebase. This is supported by the LoggerSetup helper class, which merges the jtax log messages properties file into the jta logger using addResourceBundle. That means that jtax code can call e.g. jtaLogger.loggerI18N.warn("com.arjuna.ats.internal.jta.transaction.jts.syncproblem"); and the message key will get resolved correctly. jtaLogger.logger.* is not internationalized i.e. does not use resource bundles, so it's fine too. The problem comes with jtax code's use of e.g. jtaLogger.logMesg.getString("com.arjuna.ats.internal.jta.transaction.jts.subordinate.invalidstate") as is found in many new Exception(...) type statements and elsewhere. Since this code bypasses the loggerI18N and goes direct to the un-merged message bundle, it can resolve only jta keys, not jtax ones. Because it's used mostly in exception handlers, the problem goes unnoticed until something breaks, at which point you fail to get a useful error message. -- 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 month

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2008