August 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 closed 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: Tom Jenkinson > Fix For: 5.3.4.Final, 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)

7 years, 9 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 closed 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 > ---------------------------------------------------------------------------------------------------------------------------------- > > 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.3.4.Final > > > {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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2707) Update README to reflect accurately which JDK versions we support

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2707?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2707. ------------------------------- > Update README to reflect accurately which JDK versions we support > ----------------------------------------------------------------- > > Key: JBTM-2707 > URL: https://issues.jboss.org/browse/JBTM-2707 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > We are using Java 1.8 features and the top level README needs to reflect tha. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 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 closed JBTM-2708. ------------------------------- > 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.3.4.Final, 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2699) Simple RTS quickstart doesn't work

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2699?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2699. ------------------------------- > Simple RTS quickstart doesn't work > ---------------------------------- > > Key: JBTM-2699 > URL: https://issues.jboss.org/browse/JBTM-2699 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > {code} > [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2710) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2710?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2710. ------------------------------- > XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2710 > URL: https://issues.jboss.org/browse/JBTM-2710 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back. > The scenario is following: > There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction. > # RAR is deployed > # RAR opens a java socket where listens for message > # MDB of TestResourceMessageListener is deployed > # test client sends prepare command > # test client sends commit command > # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL > # test client receives error code XAER_RMFAIL > # test client sends recover command > # test client receives number of in-doubt xid - which is one > # test client sends rollback command > # XATerminator calls rollback on the in-doubt xid > # expecting TestXAResource.rollback would be called > After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine). > [1] > {code} > 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 ) > 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2718) Make CompensatableActionImpl.WorkInfo class static

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2718?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2718. ------------------------------- > Make CompensatableActionImpl.WorkInfo class static > -------------------------------------------------- > > Key: JBTM-2718 > URL: https://issues.jboss.org/browse/JBTM-2718 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Trivial > Fix For: 5.3.4.Final > > > If inner class does not require access to an enclosing instance there should be preffered to use inner static class. > (21902 SIC: Inner class could be made static > This class is an inner class, but does not use its embedded reference to the object which created it.) > As reference I would mention Joshua Bloch: Effective Java, item 22. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 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 closed JBTM-2711. ------------------------------- > 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.3.4.Final > > > WildFly have gone to 11.0.0.Alpha1-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2721) Downgrade the version of WildFly to last released version

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2721?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2721. ------------------------------- > Downgrade the version of WildFly to last released version > --------------------------------------------------------- > > Key: JBTM-2721 > URL: https://issues.jboss.org/browse/JBTM-2721 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.4.Final > > > This would be useful in cases like https://developer.jboss.org/message/961052#961052 where the snapshot is not in nexus. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2720. ------------------------------- > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > <system-properties> > <property name="RecoveryEnvironmentBean.periodicRecoveryPeriod" value="120"/> > <property name="RecoveryEnvironmentBean.recoveryBackoffPeriod" value="10"/> > </system-properties> > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 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 August 2016