[JBoss JIRA] (JBTM-3206) StringIndexOutOfBoundsException in Spring Boot JAX-RS
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3206?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3206:
-----------------------------------
Fix Version/s: 5.next
Workaround: Workaround Exists
The workaround is to use a resource path that is non empty, something like:
{code}
@Path("not-an-empty-string")
{code}
The linked PR does fix the issue at hand though.
> StringIndexOutOfBoundsException in Spring Boot JAX-RS
> -----------------------------------------------------
>
> Key: JBTM-3206
> URL: https://issues.jboss.org/browse/JBTM-3206
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Matej Kralik
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.next
>
> Attachments: flight_5.9.6.zip
>
>
> I have two same services (flight from the lra quickstart). One is original, another is Spring Boot with JAX-RS endpoint.
> The service is sitting on the root path {code:java} http://localhost:8083 {code}
> When I run the Spring Boot application and call the endpoint, the error is thrown:
> {code:java}
> 2019-10-02 10:21:02.944 ERROR 8482 --- [nio-8083-exec-4] o.a.c.c.C.[.[.[.[.m.t.f.JerseyConfig] : Servlet.service() for servlet [org.mkralik.testing.flight.JerseyConfig] in context with path [] threw exception [java.lang.StringIndexOutOfBoundsException: String index out of range: -1] with root cause
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967) ~[na:1.8.0_222]
> at io.narayana.lra.client.NarayanaLRAClient.getTerminationUris(NarayanaLRAClient.java:398) ~[lra-client-5.9.6.Final.jar!/:5.9.6.Final]
> at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:301) ~[lra-filters-5.9.6.Final.jar!/:5.9.6.Final]
> at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:132) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:68) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:269) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:272) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:268) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors.process(Errors.java:268) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:289) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:256) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:416) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:389) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:342) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:229) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) ~[tomcat-embed-websocket-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_222]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_222]
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> I noticed that when I call the endpoint the method [containerRequestContext.getUriInfo().getPath()|https://github.com/jbosstm...] returns:
> * For original Thorntail service : "/"
> * For service in Attachment SpringBoot + JAX RS: ""
> That causes that with empty string, the [getTerminationUris|https://github.com/jbosstm/narayana/blob/master/rts/lr...] method fail on _StringIndexOutOfBoundsException_.
> I attached the project with Narayana 5.9.6 due to [JBTM-3161|https://issues.jboss.org/browse/JBTM-3161]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBTM-3206) StringIndexOutOfBoundsException in Spring Boot JAX-RS
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3206?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3206:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/1525
> StringIndexOutOfBoundsException in Spring Boot JAX-RS
> -----------------------------------------------------
>
> Key: JBTM-3206
> URL: https://issues.jboss.org/browse/JBTM-3206
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Matej Kralik
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: flight_5.9.6.zip
>
>
> I have two same services (flight from the lra quickstart). One is original, another is Spring Boot with JAX-RS endpoint.
> The service is sitting on the root path {code:java} http://localhost:8083 {code}
> When I run the Spring Boot application and call the endpoint, the error is thrown:
> {code:java}
> 2019-10-02 10:21:02.944 ERROR 8482 --- [nio-8083-exec-4] o.a.c.c.C.[.[.[.[.m.t.f.JerseyConfig] : Servlet.service() for servlet [org.mkralik.testing.flight.JerseyConfig] in context with path [] threw exception [java.lang.StringIndexOutOfBoundsException: String index out of range: -1] with root cause
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967) ~[na:1.8.0_222]
> at io.narayana.lra.client.NarayanaLRAClient.getTerminationUris(NarayanaLRAClient.java:398) ~[lra-client-5.9.6.Final.jar!/:5.9.6.Final]
> at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:301) ~[lra-filters-5.9.6.Final.jar!/:5.9.6.Final]
> at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:132) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:68) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:269) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:272) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:268) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.internal.Errors.process(Errors.java:268) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:289) ~[jersey-common-2.27.jar!/:na]
> at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:256) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703) ~[jersey-server-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:416) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:389) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:342) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:229) ~[jersey-container-servlet-core-2.27.jar!/:na]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) ~[tomcat-embed-websocket-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109) ~[spring-web-5.1.8.RELEASE.jar!/:5.1.8.RELEASE]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) ~[tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_222]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_222]
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.21.jar!/:9.0.21]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> I noticed that when I call the endpoint the method [containerRequestContext.getUriInfo().getPath()|https://github.com/jbosstm...] returns:
> * For original Thorntail service : "/"
> * For service in Attachment SpringBoot + JAX RS: ""
> That causes that with empty string, the [getTerminationUris|https://github.com/jbosstm/narayana/blob/master/rts/lr...] method fail on _StringIndexOutOfBoundsException_.
> I attached the project with Narayana 5.9.6 due to [JBTM-3161|https://issues.jboss.org/browse/JBTM-3161]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBTM-3216) Narrow the default recovery configuration in the jbossts-properties.xml files
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3216?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Ondrej Chaloupka created pull request #1524 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> Narrow the default recovery configuration in the jbossts-properties.xml files
> -----------------------------------------------------------------------------
>
> Key: JBTM-3216
> URL: https://issues.jboss.org/browse/JBTM-3216
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Configuration, JTA, JTS
> Affects Versions: 5.10.0.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
>
> There is default configuration for Narayana provided in XML files {{jbossts-properties.xml}}. They are part of the released jar files (they can be found at `META-INF` directory).
> These configuration files are different depending on the artifact. For example configuration defined in {{jbossts-properties.xml}} for JTS is different from JTA version - e.g. recovery modules are different and so.
> The configurations should be a bit narrowed to use better defaults. The discussion about this topic is at https://developer.jboss.org/message/991332
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBTM-3216) Narrow the default recovery configuration in the jbossts-properties.xml files
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3216?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka edited comment on JBTM-3216 at 10/29/19 12:54 PM:
-------------------------------------------------------------------
To summarize the available orphan filters in the Narayana code base, they are:
XAResourceOrphanFilter (com.arjuna.ats.jta.recovery)
{{JTANodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - *it works only for JTA*, otherwise ABSTAIN (JTS is not processed as JTS does not work with orphan filters (https://issues.jboss.org/browse/JBTM-2124)). If JTA it checks if the {{Xid}}'s nodename matches the node id defined at the Narayana TM (This is required, otherwise TM may start to rollback transaction which should be committed by different TM instance.). For the node name checki it calls directly the {{NodeNameXAResourceOrphanFilter}}
{{NodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - verifies that the {{Xid}} was created with this current Narayana TM by checking the node id of the TM. It's called by {{JTANodeNameXAResourceOrphanFilter}}
{{InboundBridgeRecoveryManager (org.jboss.jbossts.txbridge.inbound)}} - only for XTS
{{JTATransactionLogXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - *it works only for JTA*, otherwise ABSTAIN. If the there is a log record in the object store then abstaining to rollback this remote {{Xid}}. If there is a object store record then we expect the Xid will be committed by top-down processing or it's heuristics and it can be roll-back neither.
{{SubordinationManagerXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - *it works only for JTA*, otherwise ABSTAIN. If the subordinate transaction is in-flight then it forces for it not being rolled-back.
{{InboundBridgeOrphanFilter (org.jboss.narayana.rest.bridge.inbound)}} - only for XTS. Checks if there is no log record in the object store for not rolling-back an transaction which is expected to be commited during top-down recovery.
{{JTAActionStatusServiceXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - *it works only for JTA*, otherwise ABSTAIN. It vetoes roll-back when there is an in-flight transaction for the found {{Xid}}.
{{SubordinateJTAXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - checks if the TM as subordinate TM is responsible for this transaction (the {{Xid}} subordinate matches with the TM node identifier). If the TM is responsible and there is no transaction log in the object store then it's considered the remote {{Xid}} is subordinate orphaned and it's rolled-back.
was (Author: ochaloup):
To summarize the available orphan filters in the Narayana code base, they are:
XAResourceOrphanFilter (com.arjuna.ats.jta.recovery)
{{JTANodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN (JTS is not processed as JTS does not work with orphan filters (https://issues.jboss.org/browse/JBTM-2124)). If JTA it checks if the {{Xid}}'s nodename matches the node id defined at the Narayana TM (This is required, otherwise TM may start to rollback transaction which should be committed by different TM instance.). For the node name checki it calls directly the {{NodeNameXAResourceOrphanFilter}}
{{NodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - verifies that the {{Xid}} was created with this current Narayana TM by checking the node id of the TM. It's called by {{JTANodeNameXAResourceOrphanFilter}}
{{InboundBridgeRecoveryManager (org.jboss.jbossts.txbridge.inbound)}} - only for XTS
{{JTATransactionLogXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. If the there is a log record in the object store then abstaining to rollback this remote {{Xid}}. If there is a object store record then we expect the Xid will be committed by top-down processing or it's heuristics and it can be roll-back neither.
{{SubordinationManagerXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. If the subordinate transaction is in-flight then it forces for it not being rolled-back.
{{InboundBridgeOrphanFilter (org.jboss.narayana.rest.bridge.inbound)}} - only for XTS. Checks if there is no log record in the object store for not rolling-back an transaction which is expected to be commited during top-down recovery.
{{JTAActionStatusServiceXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. It vetoes roll-back when there is an in-flight transaction for the found {{Xid}}.
{{SubordinateJTAXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - checks if the TM as subordinate TM is responsible for this transaction (the {{Xid}} subordinate matches with the TM node identifier). If the TM is responsible and there is no transaction log in the object store then it's considered the remote {{Xid}} is subordinate orphaned and it's rolled-back.
> Narrow the default recovery configuration in the jbossts-properties.xml files
> -----------------------------------------------------------------------------
>
> Key: JBTM-3216
> URL: https://issues.jboss.org/browse/JBTM-3216
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Configuration, JTA, JTS
> Affects Versions: 5.10.0.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
>
> There is default configuration for Narayana provided in XML files {{jbossts-properties.xml}}. They are part of the released jar files (they can be found at `META-INF` directory).
> These configuration files are different depending on the artifact. For example configuration defined in {{jbossts-properties.xml}} for JTS is different from JTA version - e.g. recovery modules are different and so.
> The configurations should be a bit narrowed to use better defaults. The discussion about this topic is at https://developer.jboss.org/message/991332
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBTM-3216) Narrow the default recovery configuration in the jbossts-properties.xml files
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3216?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka commented on JBTM-3216:
----------------------------------------
To summarize the available orphan filters in the Narayana code base, they are:
XAResourceOrphanFilter (com.arjuna.ats.jta.recovery)
{{JTANodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN (JTS is not processed as JTS does not work with orphan filters (https://issues.jboss.org/browse/JBTM-2124)). If JTA it checks if the {{Xid}}'s nodename matches the node id defined at the Narayana TM (This is required, otherwise TM may start to rollback transaction which should be committed by different TM instance.). For the node name checki it calls directly the {{NodeNameXAResourceOrphanFilter}}
{{NodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - verifies that the {{Xid}} was created with this current Narayana TM by checking the node id of the TM. It's called by {{JTANodeNameXAResourceOrphanFilter}}
{{InboundBridgeRecoveryManager (org.jboss.jbossts.txbridge.inbound)}} - only for XTS
{{JTATransactionLogXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. If the there is a log record in the object store then abstaining to rollback this remote {{Xid}}. If there is a object store record then we expect the Xid will be committed by top-down processing or it's heuristics and it can be roll-back neither.
{{SubordinationManagerXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. If the subordinate transaction is in-flight then it forces for it not being rolled-back.
{{InboundBridgeOrphanFilter (org.jboss.narayana.rest.bridge.inbound)}} - only for XTS. Checks if there is no log record in the object store for not rolling-back an transaction which is expected to be commited during top-down recovery.
{{JTAActionStatusServiceXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. It vetoes roll-back when there is an in-flight transaction for the found {{Xid}}.
{{SubordinateJTAXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - checks if the TM as subordinate TM is responsible for this transaction (the {{Xid}} subordinate matches with the TM node identifier). If the TM is responsible and there is no transaction log in the object store then it's considered the remote {{Xid}} is subordinate orphaned and it's rolled-back.
> Narrow the default recovery configuration in the jbossts-properties.xml files
> -----------------------------------------------------------------------------
>
> Key: JBTM-3216
> URL: https://issues.jboss.org/browse/JBTM-3216
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Configuration, JTA, JTS
> Affects Versions: 5.10.0.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
>
> There is default configuration for Narayana provided in XML files {{jbossts-properties.xml}}. They are part of the released jar files (they can be found at `META-INF` directory).
> These configuration files are different depending on the artifact. For example configuration defined in {{jbossts-properties.xml}} for JTS is different from JTA version - e.g. recovery modules are different and so.
> The configurations should be a bit narrowed to use better defaults. The discussion about this topic is at https://developer.jboss.org/message/991332
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBTM-3216) Narrow the default recovery configuration in the jbossts-properties.xml files
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created JBTM-3216:
--------------------------------------
Summary: Narrow the default recovery configuration in the jbossts-properties.xml files
Key: JBTM-3216
URL: https://issues.jboss.org/browse/JBTM-3216
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: Configuration, JTA, JTS
Affects Versions: 5.10.0.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
There is default configuration for Narayana provided in XML files {{jbossts-properties.xml}}. They are part of the released jar files (they can be found at `META-INF` directory).
These configuration files are different depending on the artifact. For example configuration defined in {{jbossts-properties.xml}} for JTS is different from JTA version - e.g. recovery modules are different and so.
The configurations should be a bit narrowed to use better defaults. The discussion about this topic is at https://developer.jboss.org/message/991332
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBTM-3161) Nested LRA doesn't start in the Spring Boot + JAX-RS application
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3161?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3161:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Nested LRA doesn't start in the Spring Boot + JAX-RS application
> ----------------------------------------------------------------
>
> Key: JBTM-3161
> URL: https://issues.jboss.org/browse/JBTM-3161
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: LRA
> Affects Versions: 5.9.8.Final
> Reporter: Matej Kralik
> Assignee: Michael Musgrove
> Priority: Critical
> Fix For: 5.next
>
> Attachments: flight_5.9.6.zip, flight_5.9.8.zip, flight_5.9.8_working.zip
>
>
> For demonstrating purpose, I migrated flight service from [narayana quickstart|https://github.com/jbosstm/quickstart/tree/master/rts/lra/flig...] to the Spring Boot application and uploaded it to the attachment.
> When I stop debugger in the original swarm flight service (FlightParticipant [line 64|https://github.com/jbosstm/quickstart/blob/3b848517086c2abc32bff6895b2...]), the *_@HeaderParam(LRA_HTTP_CONTEXT_HEADER) String lraId_*, is new for that service. When I stop debugger in the SpringBoot+JAX-RS, the lraId is the same as for a parent. It looks that the _ServerLRAFilter_ doesn't start the new LRA.
> I add a breakpoint to the *_ServerLRAFilter.filter(...)_* to see when the filter is applied and create new LRA before the JAX-RS method. When I call original swarm flight service, the filter is used however when I call SpringBoot flight service, the filter is not used so it looks that the filter is not used at all in the SpringBoot+JAX-RS application.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months