July 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2709: --------------------------------- > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next, 4.17.35 > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2709. --------------------------------- Resolution: Done > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next, 4.17.35 > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2703) When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2703?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2703: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2703 > URL: https://issues.jboss.org/browse/JBTM-2703 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > {code} > INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory) > ERROR [stderr] java.io.IOException: java.lang.NullPointerException > ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732) > ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82) > ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393) > ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178) > ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96) > ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262) > ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > ERROR [stderr] at java.lang.Thread.run(Thread.java:745) > ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122) > ERROR [stderr] Caused by: java.lang.NullPointerException > ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697) > ERROR [stderr] ... 10 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2711) Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2711?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2711: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT > ------------------------------------------------------------ > > Key: JBTM-2711 > URL: https://issues.jboss.org/browse/JBTM-2711 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > WildFly have gone to 11.0.0.Alpha1-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2709: -------------------------------- Fix Version/s: 4.17.35 > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next, 4.17.35 > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2614: --------------------------------- > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.13.Final > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2614: -------------------------------- Fix Version/s: 4.17.35 > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.13.Final, 4.17.35 > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2614. --------------------------------- Resolution: Done > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.35, 5.2.13.Final > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2708) Test does not close FileInputStream

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2708?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2708: -------------------------------- Fix Version/s: 4.17.35 > Test does not close FileInputStream > ----------------------------------- > > Key: JBTM-2708 > URL: https://issues.jboss.org/browse/JBTM-2708 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next, 4.17.35 > > > {code} > public XARRTestResource(String xarrHelper, File file) throws IOException { > this.xarrHelper = xarrHelper; > this.file = file; > DataInputStream fis = new DataInputStream(new FileInputStream(file)); > final int formatId = fis.readInt(); > final int gtrid_length = fis.readInt(); > final byte[] gtrid = new byte[gtrid_length]; > fis.read(gtrid, 0, gtrid_length); > final int bqual_length = fis.readInt(); > final byte[] bqual = new byte[bqual_length]; > fis.read(bqual, 0, bqual_length); > xids.put(file, new Xid() { > @Override > public byte[] getGlobalTransactionId() { > return gtrid; > } > @Override > public int getFormatId() { > return formatId; > } > @Override > public byte[] getBranchQualifier() { > return bqual; > } > }); > fis.close(); > } > {code} > Spotted while working on JBTM-2614 backport -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2708) Test does not close FileInputStream

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2708?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2708. --------------------------------- Resolution: Done > Test does not close FileInputStream > ----------------------------------- > > Key: JBTM-2708 > URL: https://issues.jboss.org/browse/JBTM-2708 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > {code} > public XARRTestResource(String xarrHelper, File file) throws IOException { > this.xarrHelper = xarrHelper; > this.file = file; > DataInputStream fis = new DataInputStream(new FileInputStream(file)); > final int formatId = fis.readInt(); > final int gtrid_length = fis.readInt(); > final byte[] gtrid = new byte[gtrid_length]; > fis.read(gtrid, 0, gtrid_length); > final int bqual_length = fis.readInt(); > final byte[] bqual = new byte[bqual_length]; > fis.read(bqual, 0, bqual_length); > xids.put(file, new Xid() { > @Override > public byte[] getGlobalTransactionId() { > return gtrid; > } > @Override > public int getFormatId() { > return formatId; > } > @Override > public byte[] getBranchQualifier() { > return bqual; > } > }); > fis.close(); > } > {code} > Spotted while working on JBTM-2614 backport -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 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 July 2016