October 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1060) References to AS7 API jars in xts-build.xml are out of date

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1060?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1060. ------------------------------- > References to AS7 API jars in xts-build.xml are out of date > ----------------------------------------------------------- > > Key: JBTM-1060 > URL: https://issues.jboss.org/browse/JBTM-1060 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System, Demonstrator, XTS > Affects Versions: 4.16.2 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 4.16.3 > > > References to AS7 API jars which are required for building the XTS demo application and which are stated in XTS/demo/xts-build.xml are out of date. Moreover, they include full jar names, i.e. with particular versions which differ from time to time and significantly from AS7 to EAP6. This causes compile errors when building against EAP6. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-748) Calling rollback_only via OTS is throwing the wrong exception

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-748?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson closed JBTM-748. ------------------------------ > Calling rollback_only via OTS is throwing the wrong exception > ------------------------------------------------------------- > > Key: JBTM-748 > URL: https://issues.jboss.org/browse/JBTM-748 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Affects Versions: 4.11.0 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.15.0 > > > Occasionally our BlackTie CI test run is failing when marking a transaction rollback only because it is getting the wrong exception back from the transaction manager > 16:11:10,296 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_18] - TransactionReaper::check timeout for TX -53ee7cfb:10e2:4c0fa834:22ec in state RUN > [exec] 2010-06-09 16:11:10,296 [0x0000123c] WARN (TxLogControl :153 ) - rollback_only: INVALID_TRANSACTION minor: 20001 > 16:11:10,328 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_7] - TransactionReaper::doCancellations worker Thread[Thread-18,5,jboss] successfully canceled TX -53ee7cfb:10e2:4c0fa834:22ec > The second log message comes from the C client (the other two from the reaper). The CORBA System exception major/minor code represents INVALID_TRANSACTION/INACTIVE_TRANSACTION which according to the OTS spec is incorrect. > A look at the code shows a race condition between a BlackTie C client marking a transaction abort only and the Transaction Reaper cancelling it (due to a timeout being reached). The reaper eventually winds up in ControlImple.destroy() where the CORBA object representing the transaction is destroyed. There is a window where the C client request reaches JacORB just before the reaper has had a chance to destroy the CORBA object resulting in the wrong exception being returned. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-705) update db2, sybase test server cfg

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-705?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson closed JBTM-705. ------------------------------ > update db2, sybase test server cfg > ---------------------------------- > > Key: JBTM-705 > URL: https://issues.jboss.org/browse/JBTM-705 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 4.9.0, 4.6.1.CP04 > Reporter: Jonathan Halliday > Assignee: Ivo Studensky > Fix For: 4.10.0, 4.6.1.CP05 > > > Update the qa test config to use current versions of db2 and sybase instead of obsolete ones. see also JBQA-2860 -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-806) Convert JTS Development Guide to docbook

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-806?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson closed JBTM-806. ------------------------------ > Convert JTS Development Guide to docbook > ---------------------------------------- > > Key: JBTM-806 > URL: https://issues.jboss.org/browse/JBTM-806 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Misty Stanley-Jones > Assignee: Jonathan Halliday > Fix For: 4.14.0 > > -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson closed JBTM-895. ------------------------------ > Expose an API that allows JTA to be controlled in a distributed manner > ---------------------------------------------------------------------- > > Key: JBTM-895 > URL: https://issues.jboss.org/browse/JBTM-895 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA, JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.16.0.Final > > > This feature is requested by the Remoting team. > Options are: > ClientUserTransaction requires no additional implementation work. The same hooks that supported the earlier implementations of this can be used for the new one too. > > Transaction context inflow support falls into two parts: whole transaction (gtrid) interposition and branch only (bqual) interposition. > > For whole transaction interposition, a new subordinate transaction context is created on each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow API can be used, albeit with semantics which IMO are not spec compliant. This model would be relatively simple to implement on the transaction manager side, as the existing recovery architecture will mostly still apply. IMO it's of limited utility for users though, as resource managers will see independent transactions and not do any transaction branch coupling. That impacts both functionality and performance. > > For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid but create new branches within an allocated portion of the bqual state space. This requires information about the allocation of bqual space to be communicated, either by explicit parameter passing for the general case or by encoding in the Xid for the jboss->jboss inflow case. It affords the opportunity for branch coupling in resource managers used by more than one node in the same transaction, but leads to more complicated recovery needs. Specifically recovery can no longer be driven off consideration of the gtrid ownership alone, but must also consider bqual ownership. This naturally requires that the bqual value actually contain node ownership information, which will require a new encoding. On the other hand we probably need one anyhow to communicate delegation of the bqual state space on links where we're working with 3rd party implementations and thus constrained to the JCA api rather than one that could carry additional parameters. For links where we do control both ends, we need additional methods to support afterCompletion as a separate phase. BeforeCompletion is already available as a separate step on subordinate transactions, although it may need to be even finer grained to allow for JTA 1.1 TSR sync interposition semantics to be transaction global rather than node local. > > In both models the communication is entirely top down - the coordinator does not exist as a network endpoint as in JTS, as persistent ids are not supported by the remoting transport. This constrains recovery to use the XA recovery scan model rather than the JTS replayCompletion one. One consequence of this is that parent nodes will require to maintain a list of all possible subordinates and have a recovery module plugin for them, but that's probably not an undue burden for most deployment scenarios. Another consequence is that it's probably going to be better to build it as distributed hooks into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer better performance as resource records will get inlined to the tx rather than be separate ostore entries. > It is important that the transport should not be required to persist additional data about the transaction state in order to ensure the best performance. Any state that must be retained should be coupled to existing persistence points such as Serializable XAResources intermediaries. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1010) Tests for XTS demo and TxBridge demo apps stop working after the jboss-remoting upgrade in AS7

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1010?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1010. ------------------------------- > Tests for XTS demo and TxBridge demo apps stop working after the jboss-remoting upgrade in AS7 > ---------------------------------------------------------------------------------------------- > > Key: JBTM-1010 > URL: https://issues.jboss.org/browse/JBTM-1010 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, Testing, TxBridge, XTS > Affects Versions: 4.16.0.Beta1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 4.16.0.Final > > > The jboss-remoting has been updated in AS7 which breaks XTS demo and TxBridge demo app tests, see JBTM-947 and JBTM-948. The test projects need an upgrade of Arquillian and Drone components to get working again. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1001) The RESTful Transactions war module doesn't build

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1001?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1001. ------------------------------- > The RESTful Transactions war module doesn't build > ------------------------------------------------- > > Key: JBTM-1001 > URL: https://issues.jboss.org/browse/JBTM-1001 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.16.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.16.0.Final > > > Fails due to a missing dependency: > Non-resolvable import POM: Could not find artifact org.jboss.jbossas:jboss-as-component-matrix:pom:6.0.0.20100721-M4 in central (http://repo1.maven.org/maven2) @ line 37, column 25 -> [Help 2] -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-995) Object Store Browser Log record type handlers should be configurable via a system property

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-995?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson closed JBTM-995. ------------------------------ > Object Store Browser Log record type handlers should be configurable via a system property > ------------------------------------------------------------------------------------------ > > Key: JBTM-995 > URL: https://issues.jboss.org/browse/JBTM-995 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tooling > Affects Versions: 4.16.0.Beta1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.16.0.Final > > > MBeans for exposing log records can be configured by: > 1) calling setTypes(hash map of log record type to java class name for handling the type) on the ObjStore browser, or > 2) via the manifest for the JBossTS jar > In AS7 we call setTypes with a hardcoded map from ArjunaTransactionManagerService. Since it is not feasible to update the ts jar manifest we need a more configurable way of defining the types (this is particularly relevant for exposing SubordinateAtomicAction created in support of JBTM-895. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1011) Orphaned Subordinates are not being culled during XTS recovery

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1011?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1011. ------------------------------- > Orphaned Subordinates are not being culled during XTS recovery > -------------------------------------------------------------- > > Key: JBTM-1011 > URL: https://issues.jboss.org/browse/JBTM-1011 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: XTS > Affects Versions: 4.16.0.Final > Reporter: Paul Robinson > Assignee: Amos Feng > Priority: Critical > Fix For: 4.16.1 > > > This bug prevents orphaned subordinate transactions from being culled during recovery processing of Web service transactions. The bug is critical as it prevents correct recovery. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1138) crashrecovery12 tests intermittently fail when running in ExecutionWrapper mode

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1138?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1138. ------------------------------- > crashrecovery12 tests intermittently fail when running in ExecutionWrapper mode > ------------------------------------------------------------------------------- > > Key: JBTM-1138 > URL: https://issues.jboss.org/browse/JBTM-1138 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 4.16.3 > Reporter: Ivo Studensky > Assignee: Tom Jenkinson > Fix For: 4.16.4 > > Attachments: crashrecovery12.patch > > > The crashrecovery12 tests intermittently fail when running on HornetQ journal based object store, i.e. in ExecutionWrapper mode. > Without any patch Test03 and Test06 fail. With my patch, see attached file, the tests fail intermittently, i.e. once they fail on Test02 [1], once on Test04 [2] or on Test03 [3]. The Test06 seems to be fixed with my patch. > I did the patch according to instructions by Jonathan, but apparently I missed something. > Jonathan's instruction: > {quote} > The tests are wrong. > When in ExecutionWrapper mode, each spawned task gets its own store > unless it's explicitly told to reuse an earlier one. Most crash rec > tests that need to 'share' a store between consecutive processes for > before/after crash state have a final param to createTask that gives the > shared name, see e.g. TestGroup_crashrecovery02_01. That's missing in > the failing tests. Change the tests to add the same string as a final > param to the createTask calls and to ensure the client task is > terminated before the outcome task starts. It should be anyhow as it > commits suicide, but the framework does not necessarily know that and > may get unhappy if it think you're trying to make concurrent processes > use the same store. > Jonathan. > {quote} > [1] https://hudson.qa.jboss.com/hudson/view/JBoss%20TS/view/JBossTS-EAP6-CI/j... > [2] https://hudson.qa.jboss.com/hudson/view/JBoss%20TS/view/JBossTS-EAP6-CI/j... > [3] https://hudson.qa.jboss.com/hudson/view/JBoss%20TS/view/JBossTS-EAP6-CI/j... -- 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

11 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2013