October 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-251) Check conformance and compatibility of two JTA implementations

by Mark Little (JIRA)

Check conformance and compatibility of two JTA implementations -------------------------------------------------------------- Key: JBTM-251 URL: http://jira.jboss.com/jira/browse/JBTM-251 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: Andrew Dinn Make sure that both of our JTA implementations behave as similarly as possible from an interface perspective. For example, that timeouts are handled the same. Some differences are bound to be visible because the two implementations have different capabilities. But ignoring those, we need to be as consistent as possible. -- 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

13 years, 6 months

4
9
0 / 0

[JBoss JIRA] Created: (JBTM-336) crash recovery testing with AS integration

by Jonathan Halliday (JIRA)

crash recovery testing with AS integration ------------------------------------------ Key: JBTM-336 URL: http://jira.jboss.com/jira/browse/JBTM-336 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.3.0.BETA2 Reporter: Jonathan Halliday Fix For: 4.4 Current testing of JBossTS is standalone. The JBossAS integration code does not get exercised. This a particularly a problem for specialized crash recovery modules that are used only when running integrated with AS. Work with the AS team to figure out how best to do crash recovery testing for JBossAS. -- 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

13 years, 9 months

2
13
0 / 0

[JBoss JIRA] Created: (JBTM-624) improve transaction reaper

by Jonathan Halliday (JIRA)

improve transaction reaper -------------------------- Key: JBTM-624 URL: https://jira.jboss.org/jira/browse/JBTM-624 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.8.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.9.0 As trunk now supports jdk6 minimum, we can take better advantage of java.util.concurrent to further streamline the reaper. Whilst we are at it, we should tidy things up a bit, use generics/autoboxing and other modern conveniences. -- 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

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-594) XARecoveryModule logging is incorrect

by Jonathan Halliday (JIRA)

XARecoveryModule logging is incorrect ------------------------------------- Key: JBTM-594 URL: https://jira.jboss.org/jira/browse/JBTM-594 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.7.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.8.0 com.arjuna.ats.internal.jta.recovery.info.rollingback is incorrectly used before the check which determines if the rollback will be done or not. -- 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

13 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-489) WS-T 1.1. implementation is generating invalid faults

by Andrew Dinn (JIRA)

WS-T 1.1. implementation is generating invalid faults ----------------------------------------------------- Key: JBTM-489 URL: https://jira.jboss.org/jira/browse/JBTM-489 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.5 Reporter: Andrew Dinn Assignee: Andrew Dinn The WS-C 1.1. spec employs a slightly different set of SOAP fault codes to the 1.0 implementation. The current 1.1. implementation is still generating faults included in the 1.0 set but not in the 1.1 set, for example, NO_ACTIVITY. This may lead to interopability issues. All fault cases should be checked and, where necessary, corrected to generate faults which conform to the specification. -- 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

13 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-625) Incorrect serialization of XTS 1.1 context into service rrequests breaks interop

by Andrew Dinn (JIRA)

Incorrect serialization of XTS 1.1 context into service rrequests breaks interop -------------------------------------------------------------------------------- Key: JBTM-625 URL: https://jira.jboss.org/jira/browse/JBTM-625 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.8.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.9.0 The XTS 1.1. client and service SOAP handlers which serialize and deserialize the transaction context into/out of web service requests are not generating the headers correctly. During serialization the context is embedded into a wscoor:CoordinationContext header element, i.e. the message contains two nested elements with this tag. The mistake is consistent in the deserialization code so it does not show during normal.JBoss to JBoss operation. However., it does break interoperability. -- 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

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-635) tackle host and process id lock contention

by Jonathan Halliday (JIRA)

tackle host and process id lock contention ------------------------------------------ Key: JBTM-635 URL: https://jira.jboss.org/jira/browse/JBTM-635 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.8.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.9.0 The Utility methods for getting host inet addr and process id are heavily used (by Uid creation) and need to be as fast as possible. Revisit caching and synchronization to streamline these. -- 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

14 years

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-632) tackle ActionManager lock contention

by Jonathan Halliday (JIRA)

tackle ActionManager lock contention ------------------------------------ Key: JBTM-632 URL: https://jira.jboss.org/jira/browse/JBTM-632 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.8.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.9.0 ActionManager uses a Hashtable for _allActions. Under high load this is becomes a bottleneck. Move to ConcurrentHashMap. -- 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

14 years

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-613) TxControl.getStore should not recreate ObjectStore on each call

by Jonathan Halliday (JIRA)

TxControl.getStore should not recreate ObjectStore on each call --------------------------------------------------------------- Key: JBTM-613 URL: https://jira.jboss.org/jira/browse/JBTM-613 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.7.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.8.0 The TxControl.getStore method creates a new ObjectStore instance each time it's called i.e. for every tx. Since creation steps though some complex and highly synchronized inventory/naming code, it's expensive. The store instance should be created once and cached by TxControl. -- 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

14 years

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-530) Thrown Exceptions often loose the original cause

by Davide Cavestro (JIRA)

Thrown Exceptions often loose the original cause ------------------------------------------------ Key: JBTM-530 URL: https://jira.jboss.org/jira/browse/JBTM-530 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.5.0 Reporter: Davide Cavestro In JBossTM exceptions are often catched and left behind in favor of a new dedicated Exception (or Error) contextually thrown. This lead to a steady lack of information about the origin of the final symptom. As an example, see the following code snippet (extracted from com.arjuna.ats.internal.arjuna.objectstore.JDBCStore.JDBCStore()) ... try { initialise(""); } catch (Exception e) { throw new ObjectStoreError(); } ... Here the original exception "e" is lost in favor of a new ObjectStoreError. No one will never know the cause of the thrown ObjectStoreError, nor see what's wrong without using a debugger (if ever available). Since I saw the binary distribution of JBossTM (at least version 4.5.0) is compiled for Java 1.5, I suppose you aren't denied to use the standard exception chaining mechanism introduced since Java 1.4 (namely the java.lang.Throwable.cause field) Please consider refactoring your code to chain the exception causes. It would be very useful. -- 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

14 years, 1 month

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2009