July 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3038?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3038: -------------------------------- Issue Type: Task (was: Bug) > Include the checkstyle plugin in LRA maven poms > ----------------------------------------------- > > Key: JBTM-3038 > URL: https://issues.jboss.org/browse/JBTM-3038 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. > Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: > {code} >  > <dependency> > <groupId>org.wildfly.swarm</groupId> > <artifactId>checkstyle-config</artifactId> > <version>1</version> > </dependency> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3031: -------------------------------- Fix Version/s: 5.next > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > <MessageID xmlns="http://www.w3.org/2005/08/addressing">testAlreadyRegisteredProtocolIdentifierException</Messag...> > <To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/ws-c11/RegistrationService</To> > <ReplyTo xmlns="http://www.w3.org/2005/08/addressing"> > <Address>http://localhost:8080/ws-c11/RegistrationResponseService</Address> > </ReplyTo> > <FaultTo xmlns="http://www.w3.org/2005/08/addressing"> > <Address>http://localhost:8080/ws-c11/CoordinationFaultService</Address> > </FaultTo> > <wsarj:InstanceIdentifier xmlns:wsarj="http://schemas.arjuna.com/ws/2005/10/wsarj" xmlns="http://www.w3.org/2005/08/addressing" xmlns:wsa="http://www.w3.org/2005/08/addressing" wsa:IsReferenceParameter="1">identifier</wsarj:InstanceIdentifier> > </soap:Header> > <soap:Body> > <Register xmlns="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:ns2="http://www.w3.org/2005/08/addressing"> > <ProtocolIdentifier>http://wsc.example.org/already-registered-protocol-identifier</ProtocolIdentifier> > <ParticipantProtocolService> > <ns2:Address>http://wsc.example.org/protocol-participant-service</ns2:Address> > <ns2:ReferenceParameters> > <wsarj:InstanceIdentifier xmlns:wsarj="http://schemas.arjuna.com/ws/2005/10/wsarj" xmlns:wsa="http://www.w3.org/2005/08/addressing">participant</wsarj:InstanceIdentifier> > </ns2:ReferenceParameters> > <ns2:Metadata> > <wsam:ServiceName xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsc="http://wsc.example.org/" EndpointName="ProtocolParticipantEndpoint">wsc:ProtocolParticipantService</wsam:ServiceName> > </ns2:Metadata> > </ParticipantProtocolService> > </Register> > </soap:Body> > </soap:Envelope><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <Action xmlns="http://www.w3.org/2005/08/addressing">http://schemas.xmlsoap.org/wsdl/soap/envelope/fault</Act...> > <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c</MessageID> > <To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/ws-c11/CoordinationFaultService</T...> > <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">testAlreadyRegisteredProtocolIdentifierException</Relate...> > </soap:Header> > <soap:Body> > <soap:Fault> > <faultcode xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">wscoor:CannotRegister</faultcode> > <faultstring>Sender</faultstring> > <detail> > <wscoor:CannotRegister xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">ARJUNA042081: Participant already registered</wscoor:CannotRegister> > </detail> > </soap:Fault> > </soap:Body> > </soap:Envelope> > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: <soap:Header> > <Action xmlns="http://www.w3.org/2005/08/addressing">http://schemas.xmlsoap.org/wsdl/soap/envelope/fault</Act...> > <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584</MessageID> > <To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/ws-c11/CoordinationFaultService</T...> > <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">testUnknownCoordinationType</RelatesTo> > </soap:Header> > <soap:Body> > <soap:Fault> > <faultcode xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">wscoor:InvalidProtocol</faultcode> > <faultstring>Sender</faultstring> > <detail> > <wscoor:InvalidParameters xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">ARJUNA042082: Invalid protocol identifier</wscoor:InvalidParameters> > </detail> > </soap:Fault> > </soap:Body> > </soap:Envelope> > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3037) LRA context is not always removed if the LRA is ended

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3037?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-3037. --------------------------------- Resolution: Done > LRA context is not always removed if the LRA is ended > ----------------------------------------------------- > > Key: JBTM-3037 > URL: https://issues.jboss.org/browse/JBTM-3037 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The following scenario leaves the LRA context still current: > start an LRA > call a service annotated with, for example, > {code} > @LRA(value = LRA.Type.REQUIRED, cancelOn = {Response.Status.NOT_FOUND}) > {/code} > If the invoked method returns the NOT_FOUND status then the LRA is automatically terminated. When the request returns to the client there should be no current LRA context active. The issue here is that the next request that the client makes may still have the old LRA still associated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3037) LRA context is not always removed if the LRA is ended

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3037?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-3037: ------------------------------------- I am not sure how this didn't link up with GitHub but the commit is here: https://github.com/jbosstm/narayana/commit/3c4b7c08f310eadb7cc87f9dfb1223... > LRA context is not always removed if the LRA is ended > ----------------------------------------------------- > > Key: JBTM-3037 > URL: https://issues.jboss.org/browse/JBTM-3037 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The following scenario leaves the LRA context still current: > start an LRA > call a service annotated with, for example, > {code} > @LRA(value = LRA.Type.REQUIRED, cancelOn = {Response.Status.NOT_FOUND}) > {/code} > If the invoked method returns the NOT_FOUND status then the LRA is automatically terminated. When the request returns to the client there should be no current LRA context active. The issue here is that the next request that the client makes may still have the old LRA still associated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3034: ---------------------------------- Status: Pull Request Sent (was: Open) > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3034: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1343 > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-3034: --------------------------------------- Based on the discussion on the forum [https://developer.jboss.org/message/983892|https://developer.jboss.org/me...] there should not be the issue of {{XATerminator}} which would not be capable to commit the inflow transaction. By reverting back the change introduced by JBTM-2734 at XARecoveryModule#getNewXAResource https://github.com/jbosstm/narayana/pull/1059/files#diff-8487f43e773b3321... we should not cause any functionality error (possible a warning log message nonxaresourcerecovery could be shown in some tooling corner cases). I have tried to use different approach, than the reverting one which will be published in PR, which is checking in XARecoveryModule if CMRRecoveryModule knows about the XAResource. It's presented in branch https://github.com/ochaloup/narayana/tree/JBTM-3034-cmr-failures and the changeset is uploaded here in diff at https://issues.jboss.org/secure/attachment/12437356/JBTM-3034-xarm-to-que... > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3034: ---------------------------------- Attachment: JBTM-3034-xarm-to-query-cmrrm.diff > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2928) Provide WS-AT Integration with .NET

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2928?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2928: -------------------------------- Fix Version/s: 5.5.32.Final > Provide WS-AT Integration with .NET > ----------------------------------- > > Key: JBTM-2928 > URL: https://issues.jboss.org/browse/JBTM-2928 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Affects Versions: 5.7.2.Final > Reporter: Jörg Bäsner > Fix For: 5.8.0.Final, 5.5.32.Final > > > Provide WS-AT integration for .NET -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store.

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-3017. --------------------------------- Fix Version/s: 5.5.32.Final Resolution: Done > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.5.32.Final, 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 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 July 2018