January 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1429) Document the PartcipantCompletion race condition

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1429?page=com.atlassian.jira.plugin.... ] Paul Robinson logged work on JBTM-1429: --------------------------------------- Author: Paul Robinson Created on: 21/Jan/13 9:58 AM Start Date: 21/Jan/13 9:58 AM Worklog Time Spent: 4 hours Issue Time Tracking ------------------- Remaining Estimate: 1 day (was: 1 day, 4 hours) Time Spent: 1 day (was: 4 hours) Worklog Id: (was: 12428423) > Document the PartcipantCompletion race condition > ------------------------------------------------ > > Key: JBTM-1429 > URL: https://issues.jboss.org/browse/JBTM-1429 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M2 > > Original Estimate: 3 days > Time Spent: 1 day > Remaining Estimate: 1 day > > * Add logging to WARN when it happens > * Add explanation of why and when it happens to XTS docs and how to spot if you have it > * Blog about it > * Link to the docs in the quickstart -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1391) Prepare a blog post to introduce the TXFramework

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1391?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1391: ------------------------------------- It won't affect release, but it needs doing soon after. I wouldn't want to delay it until M3. I guess things like this are hard to model with Jira. It's priority is 'minor' for the release, but 'major' for soon after. > Prepare a blog post to introduce the TXFramework > ------------------------------------------------ > > Key: JBTM-1391 > URL: https://issues.jboss.org/browse/JBTM-1391 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation, TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M2 > > Original Estimate: 2 days > Time Spent: 4 hours > Remaining Estimate: 1 day, 4 hours > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1356: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Parallel prepare implementation does not handle LRCO correctly > -------------------------------------------------------------- > > Key: JBTM-1356 > URL: https://issues.jboss.org/browse/JBTM-1356 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.0.0.M2 > > Original Estimate: 1 day > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit. > The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1391) Prepare a blog post to introduce the TXFramework

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1391?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1391: ------------------------------------- I have dropbumped the priority as it shouldn't affect the release? > Prepare a blog post to introduce the TXFramework > ------------------------------------------------ > > Key: JBTM-1391 > URL: https://issues.jboss.org/browse/JBTM-1391 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation, TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M2 > > Original Estimate: 2 days > Time Spent: 4 hours > Remaining Estimate: 1 day, 4 hours > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1391) Prepare a blog post to introduce the TXFramework

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1391?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1391: -------------------------------- Priority: Minor (was: Major) > Prepare a blog post to introduce the TXFramework > ------------------------------------------------ > > Key: JBTM-1391 > URL: https://issues.jboss.org/browse/JBTM-1391 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation, TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M2 > > Original Estimate: 2 days > Time Spent: 4 hours > Remaining Estimate: 1 day, 4 hours > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1396) TXBridge quickstart with three servers fails because of not enough PermGen space

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1396?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1396: -------------------------------- Component/s: (was: Demonstrator) > TXBridge quickstart with three servers fails because of not enough PermGen space > -------------------------------------------------------------------------------- > > Key: JBTM-1396 > URL: https://issues.jboss.org/browse/JBTM-1396 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TxBridge > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 4.17.4, 5.0.0.M2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > See: > http://172.17.131.2/job/btny-narayana-quickstarts/166 > http://172.17.131.2/job/btny-narayana-quickstarts/167 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1396) TXBridge quickstart with three servers fails because of not enough PermGen space

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1396?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1396: -------------------------------- Component/s: Demonstrator TxBridge > TXBridge quickstart with three servers fails because of not enough PermGen space > -------------------------------------------------------------------------------- > > Key: JBTM-1396 > URL: https://issues.jboss.org/browse/JBTM-1396 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, TxBridge > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 4.17.4, 5.0.0.M2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > See: > http://172.17.131.2/job/btny-narayana-quickstarts/166 > http://172.17.131.2/job/btny-narayana-quickstarts/167 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1432) Provide information about the uid of the transaction that you are aborting

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1432?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1432: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/205 > Provide information about the uid of the transaction that you are aborting > -------------------------------------------------------------------------- > > Key: JBTM-1432 > URL: https://issues.jboss.org/browse/JBTM-1432 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.4, 5.0.0.M2 > > > I came across the following investigating a support case: > https://community.jboss.org/wiki/TxMultipleThreads > This article is excellent, however it highlighted to me a slight deficiency in the "The transaction is not active!" log statement. > I think we should put the uid of the transaction in this statement too, this can then be cross referenced against the statement: "Abort of action id -3f57cb74:c9a4:499eb149:a92 invoked while multiple threads active within it." > It would look something like: "The transaction is not active! Uid is -3f57cb74:c9a4:499eb149:a92" > This means that without turning on tracing you can be sure that your XAR was not wedged because you can see the business logic at least attempting to complete the transaction. It will also be useful to help a customer determine a suitable timeout value as often the logging is accompanied by timestamps so it will be quite straight forward to work out how much longer to add to the timeouts. > As I mentioned, this information *is* available today, but you have to enable tracing on the logging which is not always acceptable in a production environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1432) Provide information about the uid of the transaction that you are aborting

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1432?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1432: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Provide information about the uid of the transaction that you are aborting > -------------------------------------------------------------------------- > > Key: JBTM-1432 > URL: https://issues.jboss.org/browse/JBTM-1432 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.4, 5.0.0.M2 > > > I came across the following investigating a support case: > https://community.jboss.org/wiki/TxMultipleThreads > This article is excellent, however it highlighted to me a slight deficiency in the "The transaction is not active!" log statement. > I think we should put the uid of the transaction in this statement too, this can then be cross referenced against the statement: "Abort of action id -3f57cb74:c9a4:499eb149:a92 invoked while multiple threads active within it." > It would look something like: "The transaction is not active! Uid is -3f57cb74:c9a4:499eb149:a92" > This means that without turning on tracing you can be sure that your XAR was not wedged because you can see the business logic at least attempting to complete the transaction. It will also be useful to help a customer determine a suitable timeout value as often the logging is accompanied by timestamps so it will be quite straight forward to work out how much longer to add to the timeouts. > As I mentioned, this information *is* available today, but you have to enable tracing on the logging which is not always acceptable in a production environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-919) Convert tests to work on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-919?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-919: ------------------------------- Assignee: Ondřej Chaloupka > Convert tests to work on Windows > -------------------------------- > > Key: JBTM-919 > URL: https://issues.jboss.org/browse/JBTM-919 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Testing > Reporter: Tom Jenkinson > Assignee: Ondřej Chaloupka > Priority: Minor > > Some of the tests cannot be ran on Windows which reduces our scope for testing and also leaves some hudson nodes idle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2013