July 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-592) Add fallback for Utility::hostInetAddr()

by Jesper Pedersen (JIRA)

Add fallback for Utility::hostInetAddr() ---------------------------------------- Key: JBTM-592 URL: https://jira.jboss.org/jira/browse/JBTM-592 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Common Affects Versions: 4.6.1 Reporter: Jesper Pedersen Priority: Minor If a host has a misconfigured hostname Utility::hostInetAddr() fails with an UnknownHostException. An extra try could be made after logging a warning about the failed InetAddress.getLocalHost() using InetAddress.getByName(null) - e.g. try { addr = InetAddress.getLocalHost(); } catch (UnknownHostException uhe) { log.warn("Unable to use InetAddress.getLocalHost() to resolve address"); addr = InetAddress.getByName(null); } -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-593) read-only optimization in configuration should point general second phase instead of second phase abort.

by Vicky Kak (JIRA)

read-only optimization in configuration should point general second phase instead of second phase abort. -------------------------------------------------------------------------------------------------------- Key: JBTM-593 URL: https://jira.jboss.org/jira/browse/JBTM-593 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Vicky Kak Assignee: Mark Little I can see the read-only optimization details provided in the docs as "Enable or disable read-only optimization for the second phase abort." http://www.jboss.org/jbosstm/docs/4.2.3/manuals/html/core/ProgrammersGuid... The read-only optimization should work for second phase in general, irrespective of it being rollback/commit. The abort in "second phase abort." seems to be pointing to the rollback process in second phase. There should be a change of "second phase abort" to "second phase" -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-299) Xid pack should ignore trailing zeros

by Mark Little (JIRA)

Xid pack should ignore trailing zeros ------------------------------------- Key: JBTM-299 URL: http://jira.jboss.com/jira/browse/JBTM-299 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP6 Reporter: Mark Little Assigned To: Mark Little Priority: Minor Fix For: 4.6 It packs the whole array even if most of it is zeros. -- 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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-597) Implement subordinate coordinator for WS-BA

by Andrew Dinn (JIRA)

Implement subordinate coordinator for WS-BA ------------------------------------------- Key: JBTM-597 URL: https://jira.jboss.org/jira/browse/JBTM-597 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.7.0 Reporter: Andrew Dinn Assignee: Andrew Dinn The WS-BA protocol implementation should allow propagated transactions to be coordinated by a subordinate coordinator as currently happens with WS-AT. BA-enabled web services should be allowed to access this functionality by installing a server side JaxWS handler as per the WS-AT subordinate implementation. -- 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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-301) Failure to recover one XAResource in log fails to recover the rest

by Mark Little (JIRA)

Failure to recover one XAResource in log fails to recover the rest ------------------------------------------------------------------ Key: JBTM-301 URL: http://jira.jboss.com/jira/browse/JBTM-301 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, Recovery Reporter: Mark Little Assigned To: Mark Little Priority: Critical Fix For: 4.4 If we can't get a new XAResource from a XAResourceRecovery then restore_state on XAResourceRecord fails, which causes the activate on the entire log to fail. -- 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, 2 months

2
8
0 / 0

[JBoss JIRA] Created: (JBTM-567) reaper tests are time sensitive

by Jonathan Halliday (JIRA)

reaper tests are time sensitive ------------------------------- Key: JBTM-567 URL: https://jira.jboss.org/jira/browse/JBTM-567 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing, Transaction Core Affects Versions: 4.6.1 Reporter: Jonathan Halliday Assignee: Andrew Dinn Fix For: 4.8.0 Reaper unit tests can fail intermittently due to timing issues. This happens when e.g. a test machine is under heavy load. The tests should be more robust against this to prevent spurious build failures. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBTM-236) Timeout references microseconds for periodicity when it should be milliseconds

by Mark Little (JIRA)

Timeout references microseconds for periodicity when it should be milliseconds ------------------------------------------------------------------------------ Key: JBTM-236 URL: http://jira.jboss.com/jira/browse/JBTM-236 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Priority: Minor -- 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, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (JBTM-237) NORMAL mode for TransactionReaper sets checking period based on transaction timeout and not property

by Mark Little (JIRA)

NORMAL mode for TransactionReaper sets checking period based on transaction timeout and not property ---------------------------------------------------------------------------------------------------- Key: JBTM-237 URL: http://jira.jboss.com/jira/browse/JBTM-237 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little In the insert method the sleep period for the transaction reaper thread is continually modified to be based on the least timeout associated with the transaction added. This is fine for DYNAMIC mode, but is contrary to what NORMAL is supposed to do: scan based purely on the default scan timeout period specified in the configuration file. -- 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, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (JBTM-226) Possible race condition between top-down and bottom-up recovery

by Mark Little (JIRA)

Possible race condition between top-down and bottom-up recovery --------------------------------------------------------------- Key: JBTM-226 URL: http://jira.jboss.com/jira/browse/JBTM-226 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP4 Environment: Mac OS X, JDK 1.4.2. Reporter: Mark Little Assigned To: Mark Little Priority: Critical In local JTA recovery for non-serializable XAResources, the XAResourceRecovery implementation is needed to obtain a new XAResource. If a new resource isn't obtained (because the XAResourceRecovery instances haven't all been triggered yet), top-down recovery retries on subsequent recovery sweeps. Meanwhile, bottom up recovery can kick in and use an XAResource from a XAResourceRecovery that is now available and fail to locate any information on the transaction that will drive it top-down. Upon failing to find the transaction, it uses presumed abort and rolls back the instance, when in fact it should wait and commit it. But it doesn't do that until several phases have passed, and in which case most of the time top-down recovery will have re-run, found the XAResource and committed the transaction. I'm fairly sure this is a race condition and does exist, but am still checking. Work around exists at the moment though. -- 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, 4 months

3
9
0 / 0

[JBoss JIRA] Created: (JBTM-298) There is no way for recovery through JCA to indicate temporary failure to recover

by Mark Little (JIRA)

There is no way for recovery through JCA to indicate temporary failure to recover --------------------------------------------------------------------------------- Key: JBTM-298 URL: http://jira.jboss.com/jira/browse/JBTM-298 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 This means client-driven recovery sees a failure to recover and doesn't try again. We should give a "try again later" option (XA_RETRY). -- 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, 4 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 July 2009