From issues at jboss.org Tue Aug 1 07:14:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 1 Aug 2017 07:14:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2920: ------------------------------------- Summary: Investigate the use of transactions within a reactive microservices environment Key: JBTM-2920 URL: https://issues.jboss.org/browse/JBTM-2920 Project: JBoss Transaction Manager Issue Type: Task Environment: * Reporter: Ondra Chaloupka Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous there isn?t place for synchronous 2PC. The good fit seems to be the Saga transactions[4]. We lost ACID consistency and needs to stay with eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 1 07:18:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 1 Aug 2017 07:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2920: ---------------------------------- Description: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous there isn?t place for synchronous 2PC. The good fit seems to be the Saga transactions[4]. We lost ACID consistency and needs to stay with eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) was: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous there isn?t place for synchronous 2PC. The good fit seems to be the Saga transactions[4]. We lost ACID consistency and needs to stay with eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) > Investigate the use of transactions within a reactive microservices environment > ------------------------------------------------------------------------------- > > Key: JBTM-2920 > URL: https://issues.jboss.org/browse/JBTM-2920 > Project: JBoss Transaction Manager > Issue Type: Task > Environment: * > Reporter: Ondra Chaloupka > Labels: student > > Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. > h2. Motivation > Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. > Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous there isn?t place for synchronous 2PC. The good fit seems to be the Saga transactions[4]. We lost ACID consistency and needs to stay with eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. > Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. > But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. > h2. Steps to go > The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. > With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. > h2. Expected output > The expected output of this effort is > * A research document with state of the art. > ** Overview of what are the problem of the synchronous/blocking approach. > ** What are the other approaches that people have to this problem, > * A proof-of-concept implementation > ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices > * An example/quickstart showing this in practical terms > ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. > h2. Resources > [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) > [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) > [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) > [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) > [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) > [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) > [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) > [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) > [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) > [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) > [11] [http://www.axonframework.org] > [12] [http://eventuate.io] > [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) > [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) > [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 1 09:06:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Aug 2017 09:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2920: -------------------------------- Description: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. The good fit seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) was: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous there isn?t place for synchronous 2PC. The good fit seems to be the Saga transactions[4]. We lost ACID consistency and needs to stay with eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) > Investigate the use of transactions within a reactive microservices environment > ------------------------------------------------------------------------------- > > Key: JBTM-2920 > URL: https://issues.jboss.org/browse/JBTM-2920 > Project: JBoss Transaction Manager > Issue Type: Task > Environment: * > Reporter: Ondra Chaloupka > Labels: student > > Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. > h2. Motivation > Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. > Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. The good fit seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. > Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. > But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. > h2. Steps to go > The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. > With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. > h2. Expected output > The expected output of this effort is > * A research document with state of the art. > ** Overview of what are the problem of the synchronous/blocking approach. > ** What are the other approaches that people have to this problem, > * A proof-of-concept implementation > ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices > * An example/quickstart showing this in practical terms > ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. > h2. Resources > [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) > [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) > [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) > [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) > [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) > [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) > [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) > [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) > [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) > [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) > [11] [http://www.axonframework.org] > [12] [http://eventuate.io] > [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) > [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) > [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 1 09:07:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Aug 2017 09:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2920: -------------------------------- Description: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) was: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. The good fit seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) > Investigate the use of transactions within a reactive microservices environment > ------------------------------------------------------------------------------- > > Key: JBTM-2920 > URL: https://issues.jboss.org/browse/JBTM-2920 > Project: JBoss Transaction Manager > Issue Type: Task > Environment: * > Reporter: Ondra Chaloupka > Labels: student > > Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. > h2. Motivation > Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. > Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. > Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. > But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. > h2. Steps to go > The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. > With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. > h2. Expected output > The expected output of this effort is > * A research document with state of the art. > ** Overview of what are the problem of the synchronous/blocking approach. > ** What are the other approaches that people have to this problem, > * A proof-of-concept implementation > ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices > * An example/quickstart showing this in practical terms > ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. > h2. Resources > [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) > [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) > [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) > [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) > [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) > [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) > [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) > [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) > [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) > [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) > [11] [http://www.axonframework.org] > [12] [http://eventuate.io] > [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) > [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) > [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 1 09:08:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Aug 2017 09:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2920: -------------------------------- Description: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) was: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) > Investigate the use of transactions within a reactive microservices environment > ------------------------------------------------------------------------------- > > Key: JBTM-2920 > URL: https://issues.jboss.org/browse/JBTM-2920 > Project: JBoss Transaction Manager > Issue Type: Task > Environment: * > Reporter: Ondra Chaloupka > Labels: student > > Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. > h2. Motivation > Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. > Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. > Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. > h2. Steps to go > The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. > With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. > h2. Expected output > The expected output of this effort is > * A research document with state of the art. > ** Overview of what are the problem of the synchronous/blocking approach. > ** What are the other approaches that people have to this problem, > * A proof-of-concept implementation > ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices > * An example/quickstart showing this in practical terms > ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. > h2. Resources > [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) > [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) > [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) > [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) > [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) > [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) > [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) > [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) > [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) > [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) > [11] [http://www.axonframework.org] > [12] [http://eventuate.io] > [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) > [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) > [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 1 09:11:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 1 Aug 2017 09:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2920: ---------------------------------- Description: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. The sample project would be probably implemented with usage of the Vert.x, meybe there could be considered usage of Infinispan or AMQ7 for handling events. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) was: Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. h2. Motivation Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. h2. Steps to go The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. With that we expect usage of projects in Red Hat portfolio. We can expect the need for an event storage system (a.k.a. A scalable transaction log) - as an original thought let?s consider the AMQ7 message broker or the Infinispan. The sample project would be probably implemented with usage of the Vert.x. h2. Expected output The expected output of this effort is * A research document with state of the art. ** Overview of what are the problem of the synchronous/blocking approach. ** What are the other approaches that people have to this problem, * A proof-of-concept implementation ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices * An example/quickstart showing this in practical terms ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. h2. Resources [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) [11] [http://www.axonframework.org] [12] [http://eventuate.io] [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) > Investigate the use of transactions within a reactive microservices environment > ------------------------------------------------------------------------------- > > Key: JBTM-2920 > URL: https://issues.jboss.org/browse/JBTM-2920 > Project: JBoss Transaction Manager > Issue Type: Task > Environment: * > Reporter: Ondra Chaloupka > Labels: student > > Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. > h2. Motivation > Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. > Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. > Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. > h2. Steps to go > The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. > With that we expect usage of projects in Red Hat portfolio. The sample project would be probably implemented with usage of the Vert.x, meybe there could be considered usage of Infinispan or AMQ7 for handling events. > h2. Expected output > The expected output of this effort is > * A research document with state of the art. > ** Overview of what are the problem of the synchronous/blocking approach. > ** What are the other approaches that people have to this problem, > * A proof-of-concept implementation > ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices > * An example/quickstart showing this in practical terms > ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. > h2. Resources > [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) > [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) > [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) > [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) > [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) > [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) > [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) > [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) > [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) > [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) > [11] [http://www.axonframework.org] > [12] [http://eventuate.io] > [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) > [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) > [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:31:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 3 Aug 2017 06:31:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2921) In case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2921: ------------------------------------- Summary: In case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' Key: JBTM-2921 URL: https://issues.jboss.org/browse/JBTM-2921 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.6.3.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka For REST-AT transactions is defined that for two phase unaware participant when link 'commit-one-phase' is introduced then it is expected that in the case of processing one phase commit this link will be invoked on the participant (see https://github.com/jbosstm/documentation/blob/master/rts/docs/RESTAT-v2-latest.pdf) The current implementation does not consider the existence of this proposed link handler and calls always 'commit'. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:31:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 3 Aug 2017 06:31:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2921) RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2921: ---------------------------------- Summary: RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' (was: In case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase') > RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2921 > URL: https://issues.jboss.org/browse/JBTM-2921 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.6.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > For REST-AT transactions is defined that for two phase unaware participant when link 'commit-one-phase' is introduced then it is expected that in the case of processing one phase commit this link will be invoked on the participant (see https://github.com/jbosstm/documentation/blob/master/rts/docs/RESTAT-v2-latest.pdf) > The current implementation does not consider the existence of this proposed link handler and calls always 'commit'. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 06:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2922: ----------------------------------- Summary: Don't call ENDRSCAN if periodic recovery will do this anyway Key: JBTM-2922 URL: https://issues.jboss.org/browse/JBTM-2922 Project: JBoss Transaction Manager Issue Type: Component Upgrade Reporter: Tom Jenkinson Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 06:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2922: ----------------------------------- Assignee: Tom Jenkinson > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:36:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 3 Aug 2017 06:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2921) RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1204 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2921 > URL: https://issues.jboss.org/browse/JBTM-2921 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.6.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > For REST-AT transactions is defined that for two phase unaware participant when link 'commit-one-phase' is introduced then it is expected that in the case of processing one phase commit this link will be invoked on the participant (see https://github.com/jbosstm/documentation/blob/master/rts/docs/RESTAT-v2-latest.pdf) > The current implementation does not consider the existence of this proposed link handler and calls always 'commit'. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 06:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2922: -------------------------------- Issue Type: Enhancement (was: Component Upgrade) > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 06:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2922: -------------------------------- Fix Version/s: 5.next > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:37:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 06:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2922: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1203 > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 06:37:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 06:37:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2922: -------------------------------- Reporter: Gytis Trikleris (was: Tom Jenkinson) > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 08:05:00 2017 From: issues at jboss.org (Vaclav Tunka (JIRA)) Date: Thu, 3 Aug 2017 08:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2923) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: Vaclav Tunka created JBTM-2923: ---------------------------------- Summary: Don't call ENDRSCAN if periodic recovery will do this anyway Key: JBTM-2923 URL: https://issues.jboss.org/browse/JBTM-2923 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Vaclav Tunka Assignee: Tom Jenkinson Fix For: 5.next Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 3 08:58:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Aug 2017 08:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2922: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:49:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2922: -------------------------------- Fix Version/s: 5.6.4.Final (was: 5.next) > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.6.4.Final > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2919) Add a default jbossts-properties.xml into the Tomcat uber jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2919: -------------------------------- Fix Version/s: 5.6.4.Final (was: 5.next) > Add a default jbossts-properties.xml into the Tomcat uber jar > ------------------------------------------------------------- > > Key: JBTM-2919 > URL: https://issues.jboss.org/browse/JBTM-2919 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.4.Final > > > There is no jbossts-properties.xml in tomcat-jta Uber jar -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: 5.6.4.Final (was: 5.next) > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.5.28.Final, 5.6.4.Final > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2918) Allow setting IsSameRMOverride as default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2918: -------------------------------- Fix Version/s: 5.6.4.Final (was: 5.next) > Allow setting IsSameRMOverride as default > ----------------------------------------- > > Key: JBTM-2918 > URL: https://issues.jboss.org/browse/JBTM-2918 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.4.Final > > > When transactional driver was first written the IsSameRMOverride was not required as the default but with current databases it makes a sensible default. Provide a config option to easily set this as the default. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2919) Add a default jbossts-properties.xml into the Tomcat uber jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2919. --------------------------------- Resolution: Done > Add a default jbossts-properties.xml into the Tomcat uber jar > ------------------------------------------------------------- > > Key: JBTM-2919 > URL: https://issues.jboss.org/browse/JBTM-2919 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.4.Final > > > There is no jbossts-properties.xml in tomcat-jta Uber jar -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2918) Allow setting IsSameRMOverride as default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2918. --------------------------------- Resolution: Done > Allow setting IsSameRMOverride as default > ----------------------------------------- > > Key: JBTM-2918 > URL: https://issues.jboss.org/browse/JBTM-2918 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.4.Final > > > When transactional driver was first written the IsSameRMOverride was not required as the default but with current databases it makes a sensible default. Provide a config option to easily set this as the default. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:52:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2902) Transactional driver connections do not handle empty credentials correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2902: --------------------------------- > Transactional driver connections do not handle empty credentials correctly > -------------------------------------------------------------------------- > > Key: JBTM-2902 > URL: https://issues.jboss.org/browse/JBTM-2902 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.6.1.Final > > > Transactional driver connections only check for null credentials. If they are empty strings they are used as actual username and password, which is incorrect. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2902) Transactional driver connections do not handle empty credentials correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2902: -------------------------------- Fix Version/s: 5.5.29.Final > Transactional driver connections do not handle empty credentials correctly > -------------------------------------------------------------------------- > > Key: JBTM-2902 > URL: https://issues.jboss.org/browse/JBTM-2902 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.5.29.Final, 5.6.1.Final > > > Transactional driver connections only check for null credentials. If they are empty strings they are used as actual username and password, which is incorrect. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2903: --------------------------------- > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.5.29.Final, 5.6.2.Final > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2903: -------------------------------- Fix Version/s: 5.5.29.Final > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.5.29.Final, 5.6.2.Final > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: 5.5.29.Final > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.5.29.Final, 5.6.4.Final > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: (was: 5.5.28.Final) > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.5.29.Final, 5.6.4.Final > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2902) Transactional driver connections do not handle empty credentials correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2902. ------------------------------- Resolution: Done > Transactional driver connections do not handle empty credentials correctly > -------------------------------------------------------------------------- > > Key: JBTM-2902 > URL: https://issues.jboss.org/browse/JBTM-2902 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.5.29.Final, 5.6.1.Final > > > Transactional driver connections only check for null credentials. If they are empty strings they are used as actual username and password, which is incorrect. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2903. ------------------------------- Resolution: Done > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.5.29.Final, 5.6.2.Final > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 4 05:53:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Aug 2017 05:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2916. ------------------------------- > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.5.29.Final, 5.6.4.Final > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Aug 6 05:34:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 6 Aug 2017 05:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2922) Don't call ENDRSCAN if periodic recovery will do this anyway In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2922: ----------------------------------- Fix Version/s: 5.5.30.Final > Don't call ENDRSCAN if periodic recovery will do this anyway > ------------------------------------------------------------ > > Key: JBTM-2922 > URL: https://issues.jboss.org/browse/JBTM-2922 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.5.30.Final, 5.6.4.Final > > > Some XAResource implementations may decide to close the connection during ENDRSCAN. To facilitate interop with them we can ensure that out of bounds calls to scan the XAR leave the connection open if a full recovery scan is in flight. Doing this means that the AARM can get the XAR from the XARM module but still call commit during its phase2 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Aug 7 04:58:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 7 Aug 2017 04:58:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2921) RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2921: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2921 > URL: https://issues.jboss.org/browse/JBTM-2921 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.6.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > For REST-AT transactions is defined that for two phase unaware participant when link 'commit-one-phase' is introduced then it is expected that in the case of processing one phase commit this link will be invoked on the participant (see https://github.com/jbosstm/documentation/blob/master/rts/docs/RESTAT-v2-latest.pdf) > The current implementation does not consider the existence of this proposed link handler and calls always 'commit'. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 31 01:39:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 31 Aug 2017 01:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2797) Check the Blacktie build with JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng closed JBTM-2797. --------------------------- Resolution: Done > Check the Blacktie build with JDK 9 > ----------------------------------- > > Key: JBTM-2797 > URL: https://issues.jboss.org/browse/JBTM-2797 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie, Build System > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 31 01:40:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 31 Aug 2017 01:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2796) Investigate the Tomcat integration tests failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-2796. ----------------------------- Resolution: Deferred It needs the Tomcat to support JDK9 without the endorsed libraries > Investigate the Tomcat integration tests failure with the JDK 9 > --------------------------------------------------------------- > > Key: JBTM-2796 > URL: https://issues.jboss.org/browse/JBTM-2796 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Amos Feng > > Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 31 01:41:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 31 Aug 2017 01:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2777) Investigate the osgi test failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-2777. ----------------------------- Resolution: Deferred > Investigate the osgi test failure with the JDK 9 > ------------------------------------------------ > > Key: JBTM-2777 > URL: https://issues.jboss.org/browse/JBTM-2777 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Labels: jdk9 > > The arquillian can not start the karaf. > {code} > -Djava.endorsed.dirs=/home/zhfeng/work/zhfeng/narayana-jdk9/osgi/jta/target/apache-karaf-minimal-4.0.5/lib/endorsed is not supported. Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 31 02:45:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 31 Aug 2017 02:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2796) Investigate the Tomcat integration tests failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456632#comment-13456632 ] Tom Jenkinson commented on JBTM-2796: ------------------------------------- Please can you link in the blocking issue on Tomcat side? > Investigate the Tomcat integration tests failure with the JDK 9 > --------------------------------------------------------------- > > Key: JBTM-2796 > URL: https://issues.jboss.org/browse/JBTM-2796 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Amos Feng > > Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules -- This message was sent by Atlassian JIRA (v7.2.3#72005)