December 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2818?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2818: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Document tooling operation for deleting participants > ---------------------------------------------------- > > Key: JBTM-2818 > URL: https://issues.jboss.org/browse/JBTM-2818 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2818?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #41 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Document tooling operation for deleting participants > ---------------------------------------------------- > > Key: JBTM-2818 > URL: https://issues.jboss.org/browse/JBTM-2818 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2818: -------------------------------------- Summary: Document tooling operation for deleting participants Key: JBTM-2818 URL: https://issues.jboss.org/browse/JBTM-2818 Project: JBoss Transaction Manager Issue Type: Bug Components: Documentation Affects Versions: 5.4.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1106 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2813 > URL: https://issues.jboss.org/browse/JBTM-2813 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip > > > This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it. > That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected. > When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources) > {code} > [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to > {code} > [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2812: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Retain a log if a forget call on a resource fails > ------------------------------------------------- > > Key: JBTM-2812 > URL: https://issues.jboss.org/browse/JBTM-2812 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2814) Migrate Mark Little's TransactionalVert.x work to narayana

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2814?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2814: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Migrate Mark Little's TransactionalVert.x work to narayana > ---------------------------------------------------------- > > Key: JBTM-2814 > URL: https://issues.jboss.org/browse/JBTM-2814 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: vertx > Affects Versions: 5.next > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Migrate Mark's TransactionalVert.x repo (https://github.com/nmcl/TransactionalVert.x) to the narayana repo and port to Vert.x 3 in the process. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2817) Server startup hanging in InboundBridgeRecoveryTestCase#testCrashAfterPrepareInParticipantResource

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2817: ----------------------------------- Summary: Server startup hanging in InboundBridgeRecoveryTestCase#testCrashAfterPrepareInParticipantResource Key: JBTM-2817 URL: https://issues.jboss.org/browse/JBTM-2817 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Reporter: Tom Jenkinson Assignee: Michael Musgrove Priority: Blocker Fix For: 5.next Since WFLY-6493 - WildFly won't respond to HTTP calls during startup now causing hang in recovery in bridge: {code} I have this from the debugger hanging: "MSC service thread 1-8@2725" prio=5 tid=0x1a nid=NA runnable java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:170) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:285) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:454) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.put(ClientInvocationBuilder.java:175) at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:244) at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202) at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153) at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62) at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.<init>(InboundBridgeManager.java:60) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50) - locked <0x2aba> (a java.lang.Class) at org.wildfly.extension.rts.service.InboundBridgeService.start(InboundBridgeService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2815) Transaction manager runtime configuration is not enriched with system properties from standalone xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2815?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2815. ------------------------------- Resolution: Migrated to another ITS Migrated to another ITS https://issues.jboss.org/browse/WFLY-7785 > Transaction manager runtime configuration is not enriched with system properties from standalone xml > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2815 > URL: https://issues.jboss.org/browse/JBTM-2815 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > > I can see trouble and regression against behavior of 7.0.0.GA (and other prior 7.1.0 DR versions) where configuration of transaction manager which is defined inside of setting MBeans is not enriched from system properties which are defined as part of standalone .xm file. > When system property is set in standalone xml file as > {code} > <system-properties> > <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/> > </system-properties> > {code} > then it's not propagated to {{RecoveryEnvironmentBean}} when container is started. > I could see that method loading system properties at AbstractPropertiesFactory (https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna...) does not provide those which are part of the container config. That worked with DR8 fine. I didn't go deeper if this is really issue of TM/integration or some change in container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Amos Feng created pull request #183 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9

by Amos Feng (JIRA)

Amos Feng created JBTM-2816: ------------------------------- Summary: Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 Key: JBTM-2816 URL: https://issues.jboss.org/browse/JBTM-2816 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System, Demonstrator Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 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 December 2016