February 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-458) admin guide shows wrong class name for Facility Codes

by John Mazzitelli (JIRA)

admin guide shows wrong class name for Facility Codes ----------------------------------------------------- Key: JBTM-458 URL: https://jira.jboss.org/jira/browse/JBTM-458 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Reporter: John Mazzitelli Priority: Minor In the Administrators Guide: http://www.jboss.org/jbosstm/docs/4.2.3/manuals/html/core/AdministrationG... it says this: "Facility Code - JBossTS uses the following values defined in the class com.arjuna.common.util.logging.VisibilityLevel" It then lists the several FAC_xxx facility codes like FAC_ATOMIC_ACTION and others. These are not defined in the VisibilityLevel class. I think the full class name specified here should be: com.arjuna.ats.arjuna.logging.FacilityCode -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-315) Fix labs text

by Mark Little (JIRA)

Fix labs text ------------- Key: JBTM-315 URL: http://jira.jboss.com/jira/browse/JBTM-315 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.3.0.BETA2 Reporter: Mark Little Assigned To: Mark Little Priority: Trivial "JBoss Transactions is founded on industry proven technology and an 18 year history as a leader in distributed transactions." Was true 2 years ago. Needs to say 20+ now. -- 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
2
0 / 0

[JBoss JIRA] Created: (JBTM-283) Make sure JDBC text is clear that it should only be used outside of application servers

by Mark Little (JIRA)

Make sure JDBC text is clear that it should only be used outside of application servers --------------------------------------------------------------------------------------- Key: JBTM-283 URL: http://jira.jboss.com/jira/browse/JBTM-283 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: 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, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-332) Make sure it is clear that JBossTS can be used outside of an application server

by Mark Little (JIRA)

Make sure it is clear that JBossTS can be used outside of an application server ------------------------------------------------------------------------------- Key: JBTM-332 URL: http://jira.jboss.com/jira/browse/JBTM-332 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Mark Little Assigned To: 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, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-445) documentation issue: wrong name for cachestore in JBoss_TS_Programmers_Guide

by John Mazzitelli (JIRA)

documentation issue: wrong name for cachestore in JBoss_TS_Programmers_Guide ---------------------------------------------------------------------------- Key: JBTM-445 URL: https://jira.jboss.org/jira/browse/JBTM-445 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: John Mazzitelli Priority: Minor http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4.... "The cached store ... If overriding the object store implementation, the type of this object store is CachedStore." That's the wrong name of the type. I got a warning in the logs saying it can't find the class for "CachedStore" Server started up fine and started using the cache store when I used "CacheStore" instead (notice - without the 'd'). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-488) Completed BA Participants need to switch from sending Completed requests to sending GetStatus requests in order to detect coordinator crashes

by Andrew Dinn (JIRA)

Completed BA Participants need to switch from sending Completed requests to sending GetStatus requests in order to detect coordinator crashes --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBTM-488 URL: https://jira.jboss.org/jira/browse/JBTM-488 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: WS-T Implementation Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.6 A BA participant can be left forever in state Completed if the coordinator crashes between completion of the participant and close or cancel of the business activity in which it is enlisted. In this case there is a participant log record in the participant host transaction log and no record of the transacttion or participant in the coordinator host transaction log. This means that the participant will continue sending Completed messages to the coordinator even after reboot of the participant host. The BA spec _requires_ the coordinator to ignore such messages. Thenett result is garbage in the participant log and garbage messages on the network. The participant is at liberty to dispatch a GetStatus message in place of the Completed message, either during normal operation or at reboot. The coordinator must reply with a Status message identifying the participant state or it may dispatch a soap fault. This can be used to identify that the participant is no longer active. The current implementation should be modified to switch from sending Completed messages to sending GetStatus messages. During normal operation this should occur after some number of resends have failed to elicit a response. During recovery this should occur when the participant is reinstated. If a valid Status message is received the participant should revert to sending Completed messages and continue to do so until a state change occurs or the appropriate criterion is met for switching to sending GetStatus messages again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/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-487) Make WS-AT and WS-BA participants gradually increment the resend period when retrying prepared/completed messages

by Andrew Dinn (JIRA)

Make WS-AT and WS-BA participants gradually increment the resend period when retrying prepared/completed messages ----------------------------------------------------------------------------------------------------------------- Key: JBTM-487 URL: https://jira.jboss.org/jira/browse/JBTM-487 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.5 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.6 The current WS-AT/BA participant implementations resend prepared/completed messages at a fixed frequency until they receive a response. The period is currently defined by a settable property of class TransportTimer (which defaults to 5 seconds). It would be better if the period between resends could be configured to increase gradually up to some maximum period (obviously setting the maximum period equal to the initial period maintains the status quo). The benefit of a higher period is that it avoids resends using up the available network bandwidth when a response from the coordinator is slow. It is particularly beneficial in the case where a web service employs BA ParticipantCompletion participants since there may be a very long delay between the first completed message being sent and a subsequent close or cancel operation being dispatched by the coordinator. If the service is likely to support many long-running transactions then configuring a high maximum resend period will limit the extent to which resent messages clogg up the network. The downside of increasing the resend period is that a higher value means a higher latency before participant (bottom-up) recovery is initiated following a coordinator crash. It would also be useful if the initial and maximum resend period could be configured via bean properties associated with the XTS Service bean. Note that it only makes sense to implement this feature for retries dispatched from the participant side. Retries only occur on the coordinator side while the coordinator is waiting for a specific response from the participant and the wait will always timeout and cancel further retries in these cases (using the timeout interval defined by TransportTimer -- default 30 seconds). This change is a preliminary to a related change required to successfully recover BA participants. In order to detect coordinator crashes which occur between complete and close/cancel they need switch from sending Completed messages to sending GetStatus messages until they get a response or an invalid transaction/participant soap fault. The switchover algorithm needs to be defined to kick in compatibly with this incremental resend. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/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-444) Slow memory leak in BaseTransaction

by Andrew McDowell (JIRA)

Slow memory leak in BaseTransaction ----------------------------------- Key: JBTM-444 URL: https://jira.jboss.org/jira/browse/JBTM-444 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP7 Environment: Windows XP and Solaris, Java 1.5.0_14 Reporter: Andrew McDowell We had JBossAS running for approximately 4 weeks under extremely heavy load, and reached an OutOfMemory condition. Heap Dump analysis showed that the class com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction dominated 85% of the heap space. In the class com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction, there is a private Hashtable _timeouts, into which a thread id and a timeout value are placed when transactions are started. However, the entries in the hashtable are never removed, even if the thread dies. Given all the JBossAS invokers for EJBs create/destroy worker threads, it means that client transactions can leak approximately 600 bytes (the String, Integer and Hashtable$Entry). The _timeouts table in the heap dump had some 6 million entries and a retained heap size of over 1Gb. Our workaround to the problem is that we are actively monitoring heap size and performing rolling restarts when the heap space is too low. You may want to consider using a ThreadLocal to store the timeout instead of a Hashtable, which would accomplish the goal of storing the timeout value per thread, but would be collected if the Thread died, but I will leave implementation speculation to you unless I find the time to submit a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

5
13
0 / 0

[JBoss JIRA] Created: (JBTM-397) Pull higher-performance transaction log implementation across from backup

by Mark Little (JIRA)

Pull higher-performance transaction log implementation across from backup ------------------------------------------------------------------------- Key: JBTM-397 URL: https://jira.jboss.org/jira/browse/JBTM-397 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-485) Expose creation of WS-AT subtransactions and creation of associated WS-AT context to support JTA ==> WS-AT transaction bridging

by Andrew Dinn (JIRA)

Expose creation of WS-AT subtransactions and creation of associated WS-AT context to support JTA ==> WS-AT transaction bridging -------------------------------------------------------------------------------------------------------------------------------- Key: JBTM-485 URL: https://jira.jboss.org/jira/browse/JBTM-485 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.5 Reporter: Andrew Dinn Fix For: 4.6 Currently WS-AT subordinate transaction coordinators are only created when a transaction is activated from within an existing WS-AT transaction context. JTA ==> WS-AT bridging needs to be bale to pirate this functionality. During normal operation the bridge code needs to create and register a WS-AT subordinate coordinator when the bridge is first established. It also needs to be able to obtain a Tx Context for the transaction and to obtain the transaction id so it can log it in recovery records. At recovery time the bridge code needs to lookup a recovered subordinate transaction coordinator by transaction id. If no coordinator is found it needs to be able to determine whether this is because there is no record in the log or because the log has not been scanned yet. There is no requirement for the bridge code to be able to obtain a transaction context at recovery time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2009