From issues at jboss.org  Mon Nov 12 01:47:00 2018
From: issues at jboss.org (Amos Feng (Jira))
Date: Mon, 12 Nov 2018 01:47:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3075) Segment fault failure
 with tpacall when running the blacktie with centos7
In-Reply-To: <JIRA.12778829.1542005168000@Atlassian.JIRA>
References: <JIRA.12778829.1542005168000@Atlassian.JIRA>
	<JIRA.12778829.1542005168287@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12778829.1542005168000.420.1542005220107@Atlassian.JIRA>

Amos Feng created JBTM-3075:
-------------------------------

             Summary: Segment fault failure with tpacall when running the blacktie with centos7
                 Key: JBTM-3075
                 URL: https://issues.jboss.org/browse/JBTM-3075
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: BlackTie
    Affects Versions: 5.9.0.Final
         Environment: > you may get it by "uname -a" ?
Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

>what is the version of the gcc, you could get by "gcc --version"
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)

rpm -qa | grep -i apr
apr-1.4.8-3.el7.x86_64
apr-util-1.5.2-6.el7.x86_64
            Reporter: Amos Feng
            Assignee: Amos Feng
             Fix For: 5.later


The call stack is 
{code}
#0  0x00007ffff607d9f6 in _int_malloc () from /usr/lib64/libc.so.6
#1  0x00007ffff608010c in malloc () from /usr/lib64/libc.so.6
#2  0x00007ffff5bc3263 in allocator_alloc (in_size=<optimized out>,
    allocator=<optimized out>) at memory/unix/apr_pools.c:349
#3  apr_pool_create_ex (newpool=0x7fffffff9cf0, parent=0x640b18, abort_fn=0x0,
    allocator=0x63ca00) at memory/unix/apr_pools.c:891
#4  0x00007ffff7ae9c6d in log4cxx::helpers::Pool::Pool (this=0x7fffffff9cf0)
    at /home/hudson/blacktie/utils/apache-log4cxx/src/main/cpp/pool.cpp:34
#5  0x00007ffff7b35eb0 in log4cxx::Logger::forcedLog (this=0x652bc0,
    level1=..., message="HttpTxManager:57:ENTER HttpTxManager constructor",
    location=...)
    at /home/hudson/blacktie/utils/apache-log4cxx/src/main/cpp/logger.cpp:121
#6  0x00007ffff74b655c in atmibroker::tx::HttpTxManager::HttpTxManager (
    this=0x6853a0,
    txmUrl=0x714a60 "http://127.0.0.1:8080/rest-at-coordinator/tx/transaction-manager", resUrl=0x6ef560 "127.0.0.1:8888", __in_chrg=<optimized out>,
    __vtt_parm=<optimized out>)
    at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/HttpTxManager.cxx:57
#7  0x00007ffff74b71ea in atmibroker::tx::HttpTxManager::create (txmUrl=0x714a60 "http://127.0.0.1:8080/rest-at-coordinator/tx/transaction-ma                                                                                        nager", resUrl=0x6ef560 "127.0.0.1:8888")
    at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/HttpTxM---Type <return> to continue, or q <return> to quit---
anager.cxx:87
#8  0x00007ffff74a2c3e in atmibroker::tx::TxManager::get_instance ()  at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/TxManager.cxx:49
#9  0x00007ffff74b5255 in txx_get_control ()    at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/TxManagerc.cxx:56
#10 0x00007ffff72424c0 in tpacall (svc=0x42eb8c "some service",   idata=0x69ab20 "N", ilen=0, flags=34)
{code}

The failure looks like related to the log4xx.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Nov 13 03:08:00 2018
From: issues at jboss.org (Amos Feng (Jira))
Date: Tue, 13 Nov 2018 03:08:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3076) Upgrade the arquillian
 core and wildfly-arquillian-container
In-Reply-To: <JIRA.12779061.1542096462000@Atlassian.JIRA>
References: <JIRA.12779061.1542096462000@Atlassian.JIRA>
	<JIRA.12779061.1542096462214@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779061.1542096462000.7195.1542096480159@Atlassian.JIRA>

Amos Feng created JBTM-3076:
-------------------------------

             Summary: Upgrade the arquillian core and wildfly-arquillian-container
                 Key: JBTM-3076
                 URL: https://issues.jboss.org/browse/JBTM-3076
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: Testing
            Reporter: Amos Feng
            Assignee: Amos Feng
             Fix For: 5.next


The RTS AS integration failed and these two artifacts need to be upgraded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Nov 13 03:20:00 2018
From: issues at jboss.org (Amos Feng (Jira))
Date: Tue, 13 Nov 2018 03:20:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3076) Upgrade the arquillian
 core and wildfly-arquillian-container
In-Reply-To: <JIRA.12779061.1542096462000@Atlassian.JIRA>
References: <JIRA.12779061.1542096462000@Atlassian.JIRA>
	<JIRA.12779061.1542096462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779061.1542096462000.7295.1542097200191@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Amos Feng created pull request #1377 in GitHub
----------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Upgrade the arquillian core and wildfly-arquillian-container
> ------------------------------------------------------------
>
>                 Key: JBTM-3076
>                 URL: https://issues.jboss.org/browse/JBTM-3076
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Testing
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Major
>             Fix For: 5.next
>
>
> The RTS AS integration failed and these two artifacts need to be upgraded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 14 05:38:00 2018
From: issues at jboss.org (Shaun Appleton (Jira))
Date: Wed, 14 Nov 2018 05:38:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3077) Lock is not released when
 JTS is enabled and a timer is cancelled inside a transaction
In-Reply-To: <JIRA.12779306.1542191855000@Atlassian.JIRA>
References: <JIRA.12779306.1542191855000@Atlassian.JIRA>
	<JIRA.12779306.1542191855323@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779306.1542191855000.17200.1542191880186@Atlassian.JIRA>

Shaun Appleton created JBTM-3077:
------------------------------------

             Summary: Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
                 Key: JBTM-3077
                 URL: https://issues.jboss.org/browse/JBTM-3077
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: JTS
         Environment: EAP 6.4.18
            Reporter: Shaun Appleton


Description of problem:

Lock is held by EJB timer (TimerServiceImpl)  and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem:
https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980faa08892/ejb3/src/main/java/org/jboss/as/ejb3/timerservice/TimerServiceImpl.java#L640

Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner.

A simple fix could be to just change the lock to a semaphore, so that the other thread can release it.




Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start a JTA/JTS tx and call an EJB timer inside it
2. Make the transaction timeout
3. Capture a thread dump and see a thread like below  (0a0818b80 is locked object)
---------------------------------------------------------------------------------------------------------
"Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
    - <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
---------------------------------------------------------------------------------------------------------


Actual results:
Lock being held forever

Expected results:
Lock getting released



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 15 09:57:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 15 Nov 2018 09:57:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.29206.1542293820744@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662069#comment-13662069 ] 

Tom Jenkinson commented on JBTM-3020:
-------------------------------------

I am thinking, to achieve the same effect perhaps we can just allow XAR to implement https://docs.oracle.com/javase/7/docs/api/java/util/Comparator.html.

Any XAR that implements this would by default go before other XAR during prepare

We would sort the list before calling prepare on them.

Anything that knows it is going to return RDONLY in prepare can return -1 at that time, ideally leaving the other one (perhaps returning 0).


> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 15 12:39:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Thu, 15 Nov 2018 12:39:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.30816.1542303540243@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662193#comment-13662193 ] 

Ondra Chaloupka commented on JBTM-3020:
---------------------------------------

I'm worry it's not so straighforward. The {{com.arjuna.ats.arjuna.coordinator.AbstractRecord}} already defines the ordering methods like {{equals}}, {{lessThan}}... and the ordering depends on what Jonathan mentioned in the forum (https://developer.jboss.org/message/983601#983601).

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 15 12:39:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Thu, 15 Nov 2018 12:39:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.30821.1542303540345@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662193#comment-13662193 ] 

Ondra Chaloupka edited comment on JBTM-3020 at 11/15/18 12:38 PM:
------------------------------------------------------------------

I'm worry it's not so straighforward. The {{com.arjuna.ats.arjuna.coordinator.AbstractRecord}} already defines the ordering methods like {{equals}}, {{lessThan}}... and the ordering is complicated as Jonathan mentioned at the forum (https://developer.jboss.org/message/983601#983601).


was (Author: ochaloup):
I'm worry it's not so straighforward. The {{com.arjuna.ats.arjuna.coordinator.AbstractRecord}} already defines the ordering methods like {{equals}}, {{lessThan}}... and the ordering depends on what Jonathan mentioned in the forum (https://developer.jboss.org/message/983601#983601).

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 15 13:01:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 15 Nov 2018 13:01:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.30966.1542304860182@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662203#comment-13662203 ] 

Tom Jenkinson commented on JBTM-3020:
-------------------------------------

My suggestion is just for XAResources in fact

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 16 03:25:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Fri, 16 Nov 2018 03:25:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.33638.1542356700174@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662407#comment-13662407 ] 

Ondra Chaloupka commented on JBTM-3020:
---------------------------------------

But my understanding was that the {{XAResource}} is directly bound to the {{XAResourceRecord}}. The code of {{BasicAction}}, which can influence the logic of who will be prepared and who will not be, works with {{XAResourceRecord}}s. Or not?

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 16 05:02:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Fri, 16 Nov 2018 05:02:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.34278.1542362520306@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662473#comment-13662473 ] 

Michael Musgrove commented on JBTM-3020:
----------------------------------------

We can change the implementation of XAResourceRecord#order() to check whether or not the resource implements Comparator.

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 16 05:48:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Fri, 16 Nov 2018 05:48:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.34693.1542365280700@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662506#comment-13662506 ] 

Tom Jenkinson commented on JBTM-3020:
-------------------------------------

Good point, it works with AbstractRecord, In that case perhaps we could use XAResourceWrapper in the https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java to alter the order() (and add a resort of the list before calling prepare) perhaps just add a method to it: prepareWillBeRDONLY()

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 16 07:33:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Fri, 16 Nov 2018 07:33:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources
 to indicate XA_RDONLY on end
In-Reply-To: <JIRA.12749718.1526052127000@Atlassian.JIRA>
References: <JIRA.12749718.1526052127000@Atlassian.JIRA>
	<JIRA.12749718.1526052127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.35674.1542371580327@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662600#comment-13662600 ] 

Ondra Chaloupka commented on JBTM-3020:
---------------------------------------

It's a way, just please read what [Jonathan talked about at the forum|https://developer.jboss.org/message/983601#983601] (LastResourceRecord, useAlternativeOrdering, etc.)

> Add ability for resources to indicate XA_RDONLY on end
> ------------------------------------------------------
>
>                 Key: JBTM-3020
>                 URL: https://issues.jboss.org/browse/JBTM-3020
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: David Lloyd
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.next
>
>
> As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring.
> As expressed in the forum thread, the mechanism should not interfere with compatibility.  One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this:
> {code:java}
>     int endWithResult(Xid xid, int flags) throws XAException;
> {code}
> The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}.  A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}.  An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method.  {{XAER_RMERR}} seems like a reasonable error code for this case.  An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}.
> Since it's a subinterface of {{XAResource}}, it could also define the following default method:
> {code:java}
>     default void end(Xid xid, int flags) throws XAException {
>         endWithResult(xid, flags);
>     }
> {code}
> This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 21 05:39:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Wed, 21 Nov 2018 05:39:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3057) build javadoc failure
In-Reply-To: <JIRA.12768419.1536219121000@Atlassian.JIRA>
References: <JIRA.12768419.1536219121000@Atlassian.JIRA>
	<JIRA.12768419.1536219121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12768419.1536219121000.60751.1542796740748@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reopened JBTM-3057:
---------------------------------


> build javadoc failure
> ---------------------
>
>                 Key: JBTM-3057
>                 URL: https://issues.jboss.org/browse/JBTM-3057
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: Build System
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Major
>
> I have to disable the maven-javadoc-plugin on the JDK9 and it needs more investigation.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 21 05:49:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Wed, 21 Nov 2018 05:49:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3057) build javadoc failure
In-Reply-To: <JIRA.12768419.1536219121000@Atlassian.JIRA>
References: <JIRA.12768419.1536219121000@Atlassian.JIRA>
	<JIRA.12768419.1536219121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12768419.1536219121000.60858.1542797340143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Tom Jenkinson created pull request #1379 in GitHub
--------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Reopened)


> build javadoc failure
> ---------------------
>
>                 Key: JBTM-3057
>                 URL: https://issues.jboss.org/browse/JBTM-3057
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: Build System
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Major
>
> I have to disable the maven-javadoc-plugin on the JDK9 and it needs more investigation.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 21 06:37:00 2018
From: issues at jboss.org (Amos Feng (Jira))
Date: Wed, 21 Nov 2018 06:37:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2777) Investigate the osgi test
 failure with the JDK 9
In-Reply-To: <JIRA.12656056.1477038033000@Atlassian.JIRA>
References: <JIRA.12656056.1477038033000@Atlassian.JIRA>
	<JIRA.12656056.1477038033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656056.1477038033000.61313.1542800220547@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664483#comment-13664483 ] 

Amos Feng commented on JBTM-2777:
---------------------------------

KARAF supports the jdk9+ since 4.2.0

> 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.12.1#712002)

From issues at jboss.org  Thu Nov 22 06:28:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 22 Nov 2018 06:28:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2137) JDBCStore recovery is too
	slow
In-Reply-To: <JIRA.12536650.1396284348000@Atlassian.JIRA>
References: <JIRA.12536650.1396284348000@Atlassian.JIRA>
	<JIRA.12536650.1396284348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536650.1396284348000.69212.1542886080238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-2137:
-----------------------------------
    Priority: Major  (was: Minor)


> JDBCStore recovery is too slow
> ------------------------------
>
>                 Key: JBTM-2137
>                 URL: https://issues.jboss.org/browse/JBTM-2137
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Recovery
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.later
>
>
> The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 06:28:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 22 Nov 2018 06:28:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2137) JDBCStore recovery is too
	slow
In-Reply-To: <JIRA.12536650.1396284348000@Atlassian.JIRA>
References: <JIRA.12536650.1396284348000@Atlassian.JIRA>
	<JIRA.12536650.1396284348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536650.1396284348000.69215.1542886080299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-2137:
-----------------------------------
    Issue Type: Task  (was: Enhancement)


> JDBCStore recovery is too slow
> ------------------------------
>
>                 Key: JBTM-2137
>                 URL: https://issues.jboss.org/browse/JBTM-2137
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Recovery
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.later
>
>
> The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 06:29:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 22 Nov 2018 06:29:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2137) Failed CI job because
 JDBCStore recovery was stalled
In-Reply-To: <JIRA.12536650.1396284348000@Atlassian.JIRA>
References: <JIRA.12536650.1396284348000@Atlassian.JIRA>
	<JIRA.12536650.1396284348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536650.1396284348000.69235.1542886140568@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-2137:
-----------------------------------
    Summary: Failed CI job because JDBCStore recovery was stalled  (was: JDBCStore recovery is too slow)


> Failed CI job because JDBCStore recovery was stalled
> ----------------------------------------------------
>
>                 Key: JBTM-2137
>                 URL: https://issues.jboss.org/browse/JBTM-2137
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Recovery
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.later
>
>
> The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:13:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Thu, 22 Nov 2018 10:13:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1789) Simplify deploy plugin
 configuration and don't deploy uber (shaded) jars
In-Reply-To: <JIRA.12494787.1371743096000@Atlassian.JIRA>
References: <JIRA.12494787.1371743096000@Atlassian.JIRA>
	<JIRA.12494787.1371743096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494787.1371743096000.71046.1542899580589@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka reassigned JBTM-1789:
-------------------------------------

    Assignee: Ondra Chaloupka


> Simplify deploy plugin configuration and don't deploy uber (shaded) jars
> ------------------------------------------------------------------------
>
>                 Key: JBTM-1789
>                 URL: https://issues.jboss.org/browse/JBTM-1789
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>            Reporter: Paul Gier
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 6.later
>
>
> There is currently configuration of the maven deploy plugin in several modules to either deploy or not deploy artifacts and poms to the Maven repo.  The configuration could be simplified using properties, and the uber jars (generated by the shade plugin) should not be deployed to the Maven repository.
> Here is the current deployment status and proposed for the modules.
> ||Module Name||Current Deployment||Proposed||
> | Narayana: all | deployed | deployed |
> | Narayana: common | deployed | deployed |
> | Narayana: Arjunacore | deployed | deployed | 
> | Narayana: ArjunaCore arjuna | deployed | deployed |
> | Narayana: ArjunaCore txoj | deployed | deployed | 
> | Narayana: ArjunaCore arjunacore | deployed | {color:red} skipped {color} | 
> | Narayana: ArjunaJTA | deployed | deployed |
> | Narayana: ArjunaJTA jta | deployed | deployed | 
> | Narayana: ArjunaJTA cdi | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjunaJTA jdbc | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjunaJTA narayana-jta | deployed |  {color:red} skipped {color}  |
> | Narayana: XTS | deployed | deployed |
> | Narayana: XTS byteman_support | deployed | deployed |
> | Narayana: XTS WSAS | skipped | skipped |
> | Narayana: XTS WSAS xts-test-servlet | skipped | skipped |
> | Narayana: XTS WS-C | skipped | skipped |
> | Narayana: XTS WSCF | skipped | skipped |
> | Narayana: XTS WS-T | skipped | skipped |
> | Narayana: XTS WSTX | skipped | skipped |
> | Narayana: XTS recovery | skipped | skipped |
> | Narayana: XTS bridge | skipped | skipped |
> | Narayana: XTS sar | skipped | skipped |
> | Narayana: XTS jbossxts | deployed | deployed |
> | Narayana: XTS localjunit | skipped | skipped |
> | Narayana: XTS localjunit unit | skipped | skipped |
> | Narayana: XTS WSTX11-interop | skipped | skipped |
> | Narayana: XTS WSTFSC07-interop | skipped | skipped |
> | Narayana: XTS localjunit xtstest | skipped | skipped |
> | Narayana: XTS localjunit crash-recovery-tests | skipped | skipped |
> | Narayana: ArjunaJTS | deployed | deployed |
> | Narayana: ArjunaJTS idl | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjunaJTS idl jacorb | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjunaJTS orbportability | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjunaJTS jts | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjunaJTS jtax | skipped |  {color:red} deployed {color}  |
> | Narayana: ArjuntaJTS narayana-jts-jacorb | deployed |  {color:red} skipped {color}  |
> | Narayana: ArjunaJTS integration | deployed | deployed |
> | Narayana: rest-tx | deployed | deployed |
> | Narayana: rest-tx util | deployed | deployed |
> | Narayana: rest-tx tx (RESTful API for Atomic Transactions) | deployed | deployed |
> | Narayana: rest-tx webservice | skipped | skipped |
> | Narayana: rest-tx integration | deployed | deployed |
> | Narayana: txbridge | deployed | deployed |
> | Narayana: fileio | deployed | deployed |
> | Narayana: STM | skipped | skipped |
> | Narayana: txframework | deployed | deployed |
> | Narayana: narayana-full | skipped | skipped |
>                                                                    



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:15:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:15:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2069) Review BlackTie docs
In-Reply-To: <JIRA.12528659.1389015807000@Atlassian.JIRA>
References: <JIRA.12528659.1389015807000@Atlassian.JIRA>
	<JIRA.12528659.1389015807000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528659.1389015807000.71051.1542899700555@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-2069:
--------------------------------
    Priority: Minor  (was: Major)


> Review BlackTie docs
> --------------------
>
>                 Key: JBTM-2069
>                 URL: https://issues.jboss.org/browse/JBTM-2069
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: BlackTie, Documentation
>            Reporter: Tom Jenkinson
>            Priority: Minor
>
> Ensure no erroneous information
> Update AS7 references to WildFly
> For example:
> run.sh -> standalone.sh (changed parameters too)
> JBossAS->WildFly
> paths, are they up-to-date (for example what apps should be deployed and where)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:15:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:15:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1667) Investigate "possibly
 lost" valgrind memory issues
In-Reply-To: <JIRA.12490905.1367405957000@Atlassian.JIRA>
References: <JIRA.12490905.1367405957000@Atlassian.JIRA>
	<JIRA.12490905.1367405957000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490905.1367405957000.71062.1542899700820@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-1667:
--------------------------------
    Priority: Minor  (was: Major)


> Investigate "possibly lost" valgrind memory issues
> --------------------------------------------------
>
>                 Key: JBTM-1667
>                 URL: https://issues.jboss.org/browse/JBTM-1667
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Priority: Minor
>
> There are "possibly lost" memory issues when running BlackTie under valgrind:
> ==26112== 1,234 bytes in 21 blocks are possibly lost in loss record 56 of 58
> ==26112==    at 0x4006355: operator new(unsigned int) (vg_replace_malloc.c:214)
> ==26112==    by 0x1DC13A: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8)
> ==26112==    by 0x1DCCD7: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) (in /usr/lib/libstdc++.so.6.0.8)
> ==26112==    by 0x1DD666: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) (in /usr/lib/libstdc++.so.6.0.8)
> ==26112==    by 0x4E00DBE: bool google::protobuf::InsertIfNotPresent<std::map<std::string, std::pair<void const*, int>, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >, std::string, std::pair<void const*, int> >(std::map<std::string, std::pair<void const*, int>, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >*, std::string const&, std::pair<void const*, int> const&) (stl_pair.h:85)
> ==26112==    by 0x4E01BAF: google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&, std::pair<void const*, int>) (descriptor_database.cc:56)
> ==26112==    by 0x4DFC4E6: google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) (descriptor_database.cc:312)
> ==26112==    by 0x4DBC1FF: google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) (descriptor.cc:862)
> ==26112==    by 0x4DE4E3F: google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() (descriptor.pb.cc:656)
> ==26112==    by 0x4DE590C: __static_initialization_and_destruction_0(int, int) (descriptor.pb.cc:705)
> ==26112==    by 0x4E30495: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libprotobuf.so.7)
> ==26112==    by 0x4DA338C: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libprotobuf.so.7)
> ==26112==    by 0xAA5492: call_init (in /lib/ld-2.5.so)
> ==26112==    by 0xAA55A2: _dl_init (in /lib/ld-2.5.so)
> ==26112==    by 0xA9784E: ??? (in /lib/ld-2.5.so)
> ==26112== 
> ==26112== 303,104 bytes in 37 blocks are possibly lost in loss record 58 of 58
> ==26112==    at 0x4005B83: malloc (vg_replace_malloc.c:195)
> ==26112==    by 0x489CBB0: apr_pool_create_ex (in /usr/lib/libapr-1.so.0.2.7)
> ==26112==    by 0x489CDCE: apr_pool_initialize (in /usr/lib/libapr-1.so.0.2.7)
> ==26112==    by 0x489DB0E: apr_initialize (in /usr/lib/libapr-1.so.0.2.7)
> ==26112==    by 0x4C8EE54: log4cxx::helpers::APRInitializer::APRInitializer() (aprinitializer.cpp:41)
> ==26112==    by 0x4C8EF39: log4cxx::helpers::APRInitializer::getInstance() (aprinitializer.cpp:57)
> ==26112==    by 0x4C8F000: log4cxx::helpers::APRInitializer::initialize() (aprinitializer.cpp:63)
> ==26112==    by 0x4C514E9: log4cxx::helpers::ObjectImpl::ObjectImpl() (objectimpl.cpp:30)
> ==26112==    by 0x4C251EA: log4cxx::helpers::CharsetDecoder::CharsetDecoder() (charsetdecoder.cpp:413)
> ==26112==    by 0x4C27339: log4cxx::helpers::LocaleCharsetDecoder::LocaleCharsetDecoder() (charsetdecoder.cpp:360)
> ==26112==    by 0x4C25714: log4cxx::helpers::CharsetDecoder::createDefaultDecoder() (charsetdecoder.cpp:430)
> ==26112==    by 0x4C25789: log4cxx::helpers::CharsetDecoder::getDefaultDecoder() (charsetdecoder.cpp:435)
> ==26112==    by 0x4BFC72A: log4cxx::helpers::Transcoder::decode(std::string const&, std::string&) (transcoder.cpp:247)
> ==26112==    by 0x4C185B7: log4cxx::LogManager::getLogger(std::string const&) (logmanager.cpp:120)
> ==26112==    by 0x4CBD428: log4cxx::Logger::getLogger(char const*) (logger.cpp:496)
> ==26112==    by 0x490E768: __static_initialization_and_destruction_0(int, int) (XsdValidator.cxx:21)
> ==26112==    by 0x490E7A6: global constructors keyed to _ZN12XsdValidator6loggerE (XsdValidator.cxx:205)
> ==26112==    by 0x4913665: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libblacktie-core.so)
> ==26112==    by 0x48E4D60: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libblacktie-core.so)
> ==26112==    by 0xAA5492: call_init (in /lib/ld-2.5.so)
> ==26112==    by 0xAA55A2: _dl_init (in /lib/ld-2.5.so)
> ==26112==    by 0xA9784E: ??? (in /lib/ld-2.5.so)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:15:01 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:15:01 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1666) Investigate "still
 reachable" valgrind memory errors
In-Reply-To: <JIRA.12490904.1367404921000@Atlassian.JIRA>
References: <JIRA.12490904.1367404921000@Atlassian.JIRA>
	<JIRA.12490904.1367404921000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490904.1367404921000.71067.1542899701008@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-1666:
--------------------------------
    Priority: Minor  (was: Major)


> Investigate "still reachable" valgrind memory errors
> ----------------------------------------------------
>
>                 Key: JBTM-1666
>                 URL: https://issues.jboss.org/browse/JBTM-1666
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Priority: Minor
>
> Most of the valgrind logs are full of:
> ==9548== 4 bytes in 1 blocks are still reachable in loss record 1 of 51
> ==9548==    at 0x4027D17: operator new(unsigned int) (vg_replace_malloc.c:292)
> ==9548==    by 0x4E633A8: google::protobuf::DescriptorPool::DescriptorPool(google::protobuf::DescriptorDatabase*, google::protobuf::DescriptorPool::ErrorCollector*) (descriptor.cc:770)
> ==9548==    by 0x4E6346D: google::protobuf::(anonymous namespace)::InitGeneratedPool() (descriptor.cc:816)
> ==9548==    by 0x546E8DF: pthread_once (in /lib/libpthread-2.12.so)
> ==9548==    by 0x4E86E3F: google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() (descriptor.pb.cc:656)
> ==9548==    by 0x4E8790C: __static_initialization_and_destruction_0(int, int) (descriptor.pb.cc:705)
> ==9548==    by 0x4ED2495: ??? (in /home/hudson/workspace/blacktie-linux32/nbf/target/cxx/runtime/lib/libprotobuf.so.7)
> ==9548==    by 0x4E4538C: ??? (in /home/hudson/workspace/blacktie-linux32/nbf/target/cxx/runtime/lib/libprotobuf.so.7)
> ==9548==    by 0x400EFCE: _dl_init (in /lib/ld-2.12.so)
> ==9548==    by 0x400088E: ??? (in /lib/ld-2.12.so)
> Please can you explain what this is and whether it is a leak and if so, try to resolve it?



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:16:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:16:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1515) Investigate the overhead
 of bridging JTA to WS-AT when not needed
In-Reply-To: <JIRA.12486351.1362501782000@Atlassian.JIRA>
References: <JIRA.12486351.1362501782000@Atlassian.JIRA>
	<JIRA.12486351.1362501782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486351.1362501782000.71070.1542899760138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-1515:
--------------------------------
    Priority: Optional  (was: Major)


> Investigate the overhead of bridging JTA to WS-AT when not needed
> -----------------------------------------------------------------
>
>                 Key: JBTM-1515
>                 URL: https://issues.jboss.org/browse/JBTM-1515
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: XTS
>            Reporter: Paul Robinson
>            Priority: Optional
>
> When using default context propagation, a subordinate WS-AT transaction will be created for Web service calls made within a JTA transaction. This is wasteful if the target service does not enlist any participants in this transaction.
> We should measure the overhead that this imposes and take steps to reduce/remove it.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:17:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:17:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1577) Create a quickstart that
 shows a transaction created in EJB being propagated to an XATMI service
In-Reply-To: <JIRA.12485246.1361355838000@Atlassian.JIRA>
References: <JIRA.12485246.1361355838000@Atlassian.JIRA>
	<JIRA.12485246.1361355838000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485246.1361355838000.71073.1542899820304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-1577:
--------------------------------
    Priority: Optional  (was: Major)


> Create a quickstart that shows a transaction created in EJB being propagated to an XATMI service
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-1577
>                 URL: https://issues.jboss.org/browse/JBTM-1577
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: BlackTie, Demonstrator
>            Reporter: Tom Jenkinson
>            Priority: Optional
>




--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:19:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:19:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2765) Document Narayana Tomcat
	module
In-Reply-To: <JIRA.12653027.1475508464000@Atlassian.JIRA>
References: <JIRA.12653027.1475508464000@Atlassian.JIRA>
	<JIRA.12653027.1475508464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653027.1475508464000.71086.1542899940314@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed JBTM-2765.
-------------------------------
    Resolution: Won't Do


This is moved to the webservers github org so they should determine the required documentation

/cc [~mbabacek]

> Document Narayana Tomcat module
> -------------------------------
>
>                 Key: JBTM-2765
>                 URL: https://issues.jboss.org/browse/JBTM-2765
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Gytis Trikleris
>            Assignee: Tom Jenkinson
>            Priority: Major
>
> Tomcat module is not documented in http://narayana.io//docs/project/index.html.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:23:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:23:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2899) Consider independently
 versioning the quickstarts
In-Reply-To: <JIRA.12693407.1495451901000@Atlassian.JIRA>
References: <JIRA.12693407.1495451901000@Atlassian.JIRA>
	<JIRA.12693407.1495451901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693407.1495451901000.71114.1542900180076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed JBTM-2899.
-------------------------------
    Resolution: Won't Do


> Consider independently versioning the quickstarts
> -------------------------------------------------
>
>                 Key: JBTM-2899
>                 URL: https://issues.jboss.org/browse/JBTM-2899
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Demonstrator
>            Reporter: Tom Jenkinson
>            Priority: Major
>
> It would be clearer to know when an individual quickstart has changed.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:23:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:23:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-870) Add more XTS quickstarts
In-Reply-To: <JIRA.12446177.1314981220000@Atlassian.JIRA>
References: <JIRA.12446177.1314981220000@Atlassian.JIRA>
	<JIRA.12446177.1314981220000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446177.1314981220000.71116.1542900180120@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-870:
-------------------------------
    Priority: Optional  (was: Major)


> Add more XTS quickstarts
> ------------------------
>
>                 Key: JBTM-870
>                 URL: https://issues.jboss.org/browse/JBTM-870
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Demonstrator, XTS
>            Reporter: Paul Robinson
>            Priority: Optional
>
> See the individual sub tasks for more information.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:24:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:24:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1105) Setup client side
 interceptors based on WS-Policy in WSDL
In-Reply-To: <JIRA.12463197.1333526266000@Atlassian.JIRA>
References: <JIRA.12463197.1333526266000@Atlassian.JIRA>
	<JIRA.12463197.1333526266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463197.1333526266000.71118.1542900240117@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-1105:
--------------------------------
    Priority: Optional  (was: Major)


> Setup client side interceptors based on WS-Policy in WSDL
> ---------------------------------------------------------
>
>                 Key: JBTM-1105
>                 URL: https://issues.jboss.org/browse/JBTM-1105
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: XTS
>            Reporter: Paul Robinson
>            Priority: Optional
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is required/supported and we should be able to setup this handler chain automatically. Another benefit is that we can catch, on the client side, the situation where no WS-AT or WS-BA transaction context is present. Currently we leave it up to the service to detect and as a result we have no control over how this fault will be propagated back to the client. For example, a WrongStateException could be thrown when the service tries to enlist a participant and a transaction is not present. The Client may receive a generic fault message back or, in this case some or all of the WrongStateException. In either case, the developer of the Client is unlikely to realise that this is due to there not being a transaction present when the service was invoked. If the service mandates a WS-AT or WS-BA transaction, but none is present, then the client handler throws a suitable exception explaining what went wrong. If the service supports (i.e. it is optional) a WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
> CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be the right integration point for this feature. This is to be investigated.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


From issues at jboss.org  Thu Nov 22 10:25:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:25:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2968) Some JTS quickstarts run
	with JacORB
In-Reply-To: <JIRA.12721860.1511287039000@Atlassian.JIRA>
References: <JIRA.12721860.1511287039000@Atlassian.JIRA>
	<JIRA.12721860.1511287039000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721860.1511287039000.71120.1542900300066@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-2968:
--------------------------------
    Priority: Optional  (was: Major)


> Some JTS quickstarts run with JacORB
> ------------------------------------
>
>                 Key: JBTM-2968
>                 URL: https://issues.jboss.org/browse/JBTM-2968
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Demonstrator
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Optional
>             Fix For: 5.next
>
>
> Some of the JTS quickstarts are using JacORB. The narayana project has since changed the default ORB (OpenJDK ORB) so we should change the quickstarts to use the new default. The affected poms are:
> ArjunaJTS/pom.xml 
> ArjunaJTS/standalone/pom.xml 
> ArjunaJTS/trailmap/pom.xml



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:26:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:26:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3056) Remove the
 xts-test-servlet dependency in narayana-full
In-Reply-To: <JIRA.12768055.1536070713000@Atlassian.JIRA>
References: <JIRA.12768055.1536070713000@Atlassian.JIRA>
	<JIRA.12768055.1536070713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12768055.1536070713000.71122.1542900360061@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reassigned JBTM-3056:
-----------------------------------

    Assignee:     (was: Amos Feng)


> Remove the xts-test-servlet dependency in narayana-full
> -------------------------------------------------------
>
>                 Key: JBTM-3056
>                 URL: https://issues.jboss.org/browse/JBTM-3056
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: XTS
>            Reporter: Amos Feng
>            Priority: Major
>
> this dependency is generated by the module XTS/WSAS/xts-test-servlet but does not produce any files. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:27:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:27:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2483) Investigate ways to test
 Docker quickstarts
In-Reply-To: <JIRA.12580399.1438788210000@Atlassian.JIRA>
References: <JIRA.12580399.1438788210000@Atlassian.JIRA>
	<JIRA.12580399.1438788210000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580399.1438788210000.71128.1542900420304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reassigned JBTM-2483:
-----------------------------------

    Assignee:     (was: Amos Feng)


> Investigate ways to test Docker quickstarts
> -------------------------------------------
>
>                 Key: JBTM-2483
>                 URL: https://issues.jboss.org/browse/JBTM-2483
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Cloud
>            Reporter: Gytis Trikleris
>            Priority: Major
>             Fix For: 5.later
>
>
> Currently there is only one quickstart for docker (https://github.com/jbosstm/quickstart/tree/master/jts-docker), but its tests are disabled by default. However, it would be good to run them in our CI.
> We'll have the same problem in the future with Kubernetes quickstarts.
> Maybe Arquillian Cube is something what could help?



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:32:02 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:32:02 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-887) Simple WS-AT recovery
	quickstart
In-Reply-To: <JIRA.12446977.1316007512000@Atlassian.JIRA>
References: <JIRA.12446977.1316007512000@Atlassian.JIRA>
	<JIRA.12446977.1316007512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446977.1316007512000.71191.1542900722263@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-887:
-------------------------------
    Priority: Optional  (was: Major)


> Simple WS-AT recovery quickstart
> --------------------------------
>
>                 Key: JBTM-887
>                 URL: https://issues.jboss.org/browse/JBTM-887
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: Demonstrator, XTS
>            Reporter: Paul Robinson
>            Priority: Optional
>
> This quickstart shows what happens when a participant fails at various points in the protocol.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:32:02 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:32:02 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-886) Simple WS-BA recovery
	quickstart
In-Reply-To: <JIRA.12446976.1316007448000@Atlassian.JIRA>
References: <JIRA.12446976.1316007448000@Atlassian.JIRA>
	<JIRA.12446976.1316007448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446976.1316007448000.71193.1542900722769@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-886:
-------------------------------
    Priority: Optional  (was: Major)


> Simple WS-BA recovery quickstart
> --------------------------------
>
>                 Key: JBTM-886
>                 URL: https://issues.jboss.org/browse/JBTM-886
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: Demonstrator, XTS
>            Reporter: Paul Robinson
>            Priority: Optional
>
> This quickstart will show what happens when a participant crashes at various key points in the protocol.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:32:05 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:32:05 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2010) Scalability Enhancements
	for BlackTie
In-Reply-To: <JIRA.12518014.1383652719000@Atlassian.JIRA>
References: <JIRA.12518014.1383652719000@Atlassian.JIRA>
	<JIRA.12518014.1383652719000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518014.1383652719000.71202.1542900725392@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-2010:
--------------------------------
    Priority: Minor  (was: Major)


> Scalability Enhancements for BlackTie
> -------------------------------------
>
>                 Key: JBTM-2010
>                 URL: https://issues.jboss.org/browse/JBTM-2010
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Priority: Minor
>
> At the moment we are using traditional IO techniques which means there is a single thread and connection per service on the C++ side and a single thread per server per service on the WildFly side.
> For example:
> 10 servers with 10 services = 10 threads on the client side, 100 threads on the wildfly side
> We should look to use AIO on the Java side and apr pollset on the C++ side to reduce the number of threads. This will not reduce the physical number of connections but should allow the server to scale much higher.
> 1. use AIO for StompConnect, 
> 2. add a configurably sized connection polling pool to BlackTie C++,
> 3. use a common pool for servicedispatchers, so for example if 10 services with a size of 10 would normally mean 100 threads, we can say 10 services, size of 10, share 10 threads.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:35:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:35:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2326) Provide a management
 interface to see a list of Xids that are being being considered for
 recovery by the recovery manager
In-Reply-To: <JIRA.12560543.1420737406000@Atlassian.JIRA>
References: <JIRA.12560543.1420737406000@Atlassian.JIRA>
	<JIRA.12560543.1420737406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560543.1420737406000.71226.1542900900199@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-2326:
--------------------------------
    Priority: Minor  (was: Major)


> Provide a management interface to see a list of Xids that are being being considered for recovery by the recovery manager
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2326
>                 URL: https://issues.jboss.org/browse/JBTM-2326
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: JTA, Tooling
>            Reporter: Tom Jenkinson
>            Priority: Minor
>             Fix For: 5.later
>
>
> Although it is possible to see the list of current transactions in the CLI, for those branches that are available for recovery it can be useful to see the list that the recovery manager is considering. I have often looked in the debugger at this state:
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java#L1017 so it might be useful to others.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 22 10:36:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 22 Nov 2018 10:36:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2471) Provide a mechanism to
 get stack dumps from the C++ binaries
In-Reply-To: <JIRA.12580150.1438609331000@Atlassian.JIRA>
References: <JIRA.12580150.1438609331000@Atlassian.JIRA>
	<JIRA.12580150.1438609331000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580150.1438609331000.71228.1542900960154@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-2471:
--------------------------------
    Priority: Minor  (was: Major)


> Provide a mechanism to get stack dumps from the C++ binaries
> ------------------------------------------------------------
>
>                 Key: JBTM-2471
>                 URL: https://issues.jboss.org/browse/JBTM-2471
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Priority: Minor
>
> Currently debugging BlackTie is problematic as we are reliant on logs to know what was happening on stack dumping the application server to guess what is being called. It would be useful to provide a method to do this.
> Potentially an open socket to connect to could dump the stacks or understanding how to do this on Windows and Linux natively.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 23 16:56:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Fri, 23 Nov 2018 16:56:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3078) JDBC transaction driver
 does not support MSSQL, the list should be enriched
In-Reply-To: <JIRA.12780838.1543010139000@Atlassian.JIRA>
References: <JIRA.12780838.1543010139000@Atlassian.JIRA>
	<JIRA.12780838.1543010139428@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12780838.1543010139000.76497.1543010160048@Atlassian.JIRA>

Ondra Chaloupka created JBTM-3078:
-------------------------------------

             Summary: JDBC transaction driver does not support MSSQL, the list should be enriched
                 Key: JBTM-3078
                 URL: https://issues.jboss.org/browse/JBTM-3078
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Transactional Driver
    Affects Versions: 5.9.0.Final
            Reporter: Ondra Chaloupka
            Assignee: Ondra Chaloupka


The transactional jdbc driver does not support MSSQL driver.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 23 17:02:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Fri, 23 Nov 2018 17:02:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3078) JDBC transaction driver
 does not support MSSQL, the list should be enriched
In-Reply-To: <JIRA.12780838.1543010139000@Atlassian.JIRA>
References: <JIRA.12780838.1543010139000@Atlassian.JIRA>
	<JIRA.12780838.1543010139000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12780838.1543010139000.76499.1543010520137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Ondra Chaloupka created pull request #1380 in GitHub
----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> JDBC transaction driver does not support MSSQL, the list should be enriched
> ---------------------------------------------------------------------------
>
>                 Key: JBTM-3078
>                 URL: https://issues.jboss.org/browse/JBTM-3078
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Transactional Driver
>    Affects Versions: 5.9.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Minor
>
> The transactional jdbc driver does not support MSSQL driver.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 23 17:45:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Fri, 23 Nov 2018 17:45:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2993)
 start-swarm-lra-coordinator : failed: Process was not healthy even after 30
 seconds
In-Reply-To: <JIRA.12734136.1518540565000@Atlassian.JIRA>
References: <JIRA.12734136.1518540565000@Atlassian.JIRA>
	<JIRA.12734136.1518540565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12734136.1518540565000.76512.1543013100163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka closed JBTM-2993.
---------------------------------
    Release Notes Text: 
I'm closing this issue for following reasons
 * the lra tests were moved to tck suite of lra microprofile spec and no lra test exist anymore in the narayana
 * I expect that failure was happening because of the timeout for starting the lra coordinator which is a timing issue and could be changed by person building the lra coordinator differently for environment

Please, re-open the issue if there is some defect in my reasoning.
            Resolution: Deferred


> start-swarm-lra-coordinator : failed: Process was not healthy even after 30 seconds 
> ------------------------------------------------------------------------------------
>
>                 Key: JBTM-2993
>                 URL: https://issues.jboss.org/browse/JBTM-2993
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>    Affects Versions: 5.8.0.Final
>         Environment: Fedora 26, OpenJDK 8, Maven 3.5.2
>            Reporter: Michal Karm Babacek
>            Assignee: Ondra Chaloupka
>            Priority: Major
>
> I had updated to the latest Narayana master and it broke the build for me on "LRA": See: [log|https://gist.github.com/Karm/2eae842cff57964af65a3341dfae873c]
> My git head: 40999b11



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon Nov 26 04:49:01 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Mon, 26 Nov 2018 04:49:01 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3067) Build and run the
	narayana with JDK-11
In-Reply-To: <JIRA.12774922.1539740656000@Atlassian.JIRA>
References: <JIRA.12774922.1539740656000@Atlassian.JIRA>
	<JIRA.12774922.1539740656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12774922.1539740656000.78198.1543225741241@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Tom Jenkinson created pull request #1381 in GitHub
--------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Build and run the narayana with JDK-11
> --------------------------------------
>
>                 Key: JBTM-3067
>                 URL: https://issues.jboss.org/browse/JBTM-3067
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Critical
>
> The jdk-11 could be downloaded from https://jdk.java.net/11/ and the most important feature that impacts us is [JEP 320: Remove the Java EE and CORBA Modules|https://openjdk.java.net/jeps/320]
> The CI job is http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-11/



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Nov 27 05:02:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Tue, 27 Nov 2018 05:02:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in
	Compensation API
In-Reply-To: <JIRA.12463204.1333527218000@Atlassian.JIRA>
References: <JIRA.12463204.1333527218000@Atlassian.JIRA>
	<JIRA.12463204.1333527218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463204.1333527218000.87336.1543312920126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Ondra Chaloupka created pull request #11885 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Recovery Support in Compensation API
> ------------------------------------
>
>                 Key: JBTM-1107
>                 URL: https://issues.jboss.org/browse/JBTM-1107
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Compensations
>            Reporter: Tom Jenkinson
>            Assignee: Ondra Chaloupka
>            Priority: Major
>             Fix For: 5.later
>
>
> *Background*
> Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash.
> *Requirements*
> # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler).
> ## Require Serializable interface.
> ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration).
> # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant).
> ## Make transaction identifier persistable (converting it to String should work).
> ## Implement PersistableParticipant in ParticipantImpl.
> ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated.
> # Make compensation scoped beans persistable.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue Nov 27 08:53:04 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Tue, 27 Nov 2018 08:53:04 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3076) Upgrade the arquillian
 core and wildfly-arquillian-container
In-Reply-To: <JIRA.12779061.1542096462000@Atlassian.JIRA>
References: <JIRA.12779061.1542096462000@Atlassian.JIRA>
	<JIRA.12779061.1542096462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12779061.1542096462000.89544.1543326784978@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-3076:
--------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Upgrade the arquillian core and wildfly-arquillian-container
> ------------------------------------------------------------
>
>                 Key: JBTM-3076
>                 URL: https://issues.jboss.org/browse/JBTM-3076
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Testing
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Major
>             Fix For: 5.next
>
>
> The RTS AS integration failed and these two artifacts need to be upgraded.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 28 05:28:01 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 28 Nov 2018 05:28:01 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3018) Migrate the LRA
 implementation to use the microprofile-lra API
In-Reply-To: <JIRA.12747935.1525180282000@Atlassian.JIRA>
References: <JIRA.12747935.1525180282000@Atlassian.JIRA>
	<JIRA.12747935.1525180282000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747935.1525180282000.95856.1543400881231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove reopened JBTM-3018:
------------------------------------


Reopened since there are sill some deprecated LRA API classes in the code base

> Migrate the LRA implementation to use the microprofile-lra API
> --------------------------------------------------------------
>
>                 Key: JBTM-3018
>                 URL: https://issues.jboss.org/browse/JBTM-3018
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: LRA
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.8.2.Final
>
>
> The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api).
> Make sure the API bundled with narayana is deprecated.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 28 06:10:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 28 Nov 2018 06:10:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3018) Migrate the LRA
 implementation to use the microprofile-lra API
In-Reply-To: <JIRA.12747935.1525180282000@Atlassian.JIRA>
References: <JIRA.12747935.1525180282000@Atlassian.JIRA>
	<JIRA.12747935.1525180282000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747935.1525180282000.96340.1543403400258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Michael Musgrove created pull request #1385 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Reopened)


> Migrate the LRA implementation to use the microprofile-lra API
> --------------------------------------------------------------
>
>                 Key: JBTM-3018
>                 URL: https://issues.jboss.org/browse/JBTM-3018
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: LRA
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.8.2.Final
>
>
> The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api).
> Make sure the API bundled with narayana is deprecated.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed Nov 28 13:05:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Wed, 28 Nov 2018 13:05:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3061) CMR recovery wrongly
 handles commit and rollback
In-Reply-To: <JIRA.12771022.1537786158000@Atlassian.JIRA>
References: <JIRA.12771022.1537786158000@Atlassian.JIRA>
	<JIRA.12771022.1537786158000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12771022.1537786158000.101013.1543428300507@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated JBTM-3061:
--------------------------------
           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 5.5.next
       Resolution: Done


> CMR recovery wrongly handles commit and rollback 
> -------------------------------------------------
>
>                 Key: JBTM-3061
>                 URL: https://issues.jboss.org/browse/JBTM-3061
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTA
>    Affects Versions: 5.5.32.Final
>            Reporter: Jiri Ondrusek
>            Assignee: Jiri Ondrusek
>            Priority: Major
>             Fix For: 5.5.next
>
>
> The recovery of CMR works wrongly.
> For scenario I currently investigate there is issue the second resource beging committed and rolled-back too.
> # cmr resource prepare (no real action on the local transction)
> # xa resource prepare (prepared in real as XA)
> # cmr resource commit (commiting the local transaction)
> # JVM crash
> # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue.
> This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed.
> This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 05:13:02 2018
From: issues at jboss.org (Jonathan Halliday (Jira))
Date: Thu, 29 Nov 2018 05:13:02 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3079) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781467.1543486357000@Atlassian.JIRA>
References: <JIRA.12781467.1543486357000@Atlassian.JIRA>
	<JIRA.12781467.1543486357061@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781467.1543486357000.104016.1543486382207@Atlassian.JIRA>

Jonathan Halliday created JBTM-3079:
---------------------------------------

             Summary: InboundBridge recovery aborts live transactions
                 Key: JBTM-3079
                 URL: https://issues.jboss.org/browse/JBTM-3079
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: TxBridge
    Affects Versions: 5.5.32.Final
         Environment: EAP 7.1.5 / 5.5.32.Final
            Reporter: Jonathan Halliday
            Assignee: Ondra Chaloupka


During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.

TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 

TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 

ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException

It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 05:15:00 2018
From: issues at jboss.org (Jonathan Halliday (Jira))
Date: Thu, 29 Nov 2018 05:15:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3079) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781467.1543486357000@Atlassian.JIRA>
References: <JIRA.12781467.1543486357000@Atlassian.JIRA>
	<JIRA.12781467.1543486357000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781467.1543486357000.104025.1543486500488@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Halliday updated JBTM-3079:
------------------------------------
    Attachment: jbtm3079.patch


> InboundBridge recovery aborts live transactions
> -----------------------------------------------
>
>                 Key: JBTM-3079
>                 URL: https://issues.jboss.org/browse/JBTM-3079
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: TxBridge
>    Affects Versions: 5.5.32.Final
>         Environment: EAP 7.1.5 / 5.5.32.Final
>            Reporter: Jonathan Halliday
>            Assignee: Ondra Chaloupka
>            Priority: Critical
>         Attachments: jbtm3079.patch
>
>
> During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
> TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 
> TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 
> ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
> It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 05:19:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Thu, 29 Nov 2018 05:19:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3079) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781467.1543486357000@Atlassian.JIRA>
References: <JIRA.12781467.1543486357000@Atlassian.JIRA>
	<JIRA.12781467.1543486357000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781467.1543486357000.104070.1543486740248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka updated JBTM-3079:
----------------------------------
    Affects Version/s: 5.9.0.Final


> InboundBridge recovery aborts live transactions
> -----------------------------------------------
>
>                 Key: JBTM-3079
>                 URL: https://issues.jboss.org/browse/JBTM-3079
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: TxBridge
>    Affects Versions: 5.5.32.Final, 5.9.0.Final
>         Environment: EAP 7.1.5 / 5.5.32.Final
>            Reporter: Jonathan Halliday
>            Assignee: Ondra Chaloupka
>            Priority: Critical
>         Attachments: jbtm3079.patch
>
>
> During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
> TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 
> TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 
> ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
> It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 06:12:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 29 Nov 2018 06:12:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3079) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781467.1543486357000@Atlassian.JIRA>
References: <JIRA.12781467.1543486357000@Atlassian.JIRA>
	<JIRA.12781467.1543486357000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781467.1543486357000.104402.1543489920399@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBTM-3079 started by Tom Jenkinson.
-------------------------------------------
> InboundBridge recovery aborts live transactions
> -----------------------------------------------
>
>                 Key: JBTM-3079
>                 URL: https://issues.jboss.org/browse/JBTM-3079
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: TxBridge
>    Affects Versions: 5.5.32.Final, 5.9.0.Final
>         Environment: EAP 7.1.5 / 5.5.32.Final
>            Reporter: Jonathan Halliday
>            Assignee: Tom Jenkinson
>            Priority: Critical
>         Attachments: jbtm3079.patch
>
>
> During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
> TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 
> TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 
> ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
> It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 06:12:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 29 Nov 2018 06:12:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3080) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781481.1543489912000@Atlassian.JIRA>
References: <JIRA.12781481.1543489912000@Atlassian.JIRA>
	<JIRA.12781481.1543489912286@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781481.1543489912000.104404.1543489920444@Atlassian.JIRA>

Tom Jenkinson created JBTM-3080:
-----------------------------------

             Summary: InboundBridge recovery aborts live transactions
                 Key: JBTM-3080
                 URL: https://issues.jboss.org/browse/JBTM-3080
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: TxBridge
    Affects Versions: 5.5.32.Final, 5.9.0.Final
         Environment: EAP 7.1.5 / 5.5.32.Final
            Reporter: Jonathan Halliday
            Assignee: Tom Jenkinson


During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.

TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 

TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 

ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException

It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 06:13:00 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 29 Nov 2018 06:13:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3080) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781481.1543489912000@Atlassian.JIRA>
References: <JIRA.12781481.1543489912000@Atlassian.JIRA>
	<JIRA.12781481.1543489912000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781481.1543489912000.104406.1543489980974@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson deleted JBTM-3080:
--------------------------------


> InboundBridge recovery aborts live transactions
> -----------------------------------------------
>
>                 Key: JBTM-3080
>                 URL: https://issues.jboss.org/browse/JBTM-3080
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>         Environment: EAP 7.1.5 / 5.5.32.Final
>            Reporter: Jonathan Halliday
>            Assignee: Tom Jenkinson
>            Priority: Critical
>
> During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
> TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 
> TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 
> ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
> It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 06:13:01 2018
From: issues at jboss.org (Tom Jenkinson (Jira))
Date: Thu, 29 Nov 2018 06:13:01 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3081) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781482.1543489937000@Atlassian.JIRA>
References: <JIRA.12781482.1543489937000@Atlassian.JIRA>
	<JIRA.12781482.1543489937018@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781482.1543489937000.104408.1543489981012@Atlassian.JIRA>

Tom Jenkinson created JBTM-3081:
-----------------------------------

             Summary: InboundBridge recovery aborts live transactions
                 Key: JBTM-3081
                 URL: https://issues.jboss.org/browse/JBTM-3081
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: TxBridge
    Affects Versions: 5.5.32.Final, 5.9.0.Final
         Environment: EAP 7.1.5 / 5.5.32.Final
            Reporter: Jonathan Halliday
            Assignee: Tom Jenkinson
         Attachments: jbtm3079.patch

During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.

TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 

TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 

ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException

It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 07:55:00 2018
From: issues at jboss.org (Ondra Chaloupka (Jira))
Date: Thu, 29 Nov 2018 07:55:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3079) InboundBridge recovery
 aborts live transactions
In-Reply-To: <JIRA.12781467.1543486357000@Atlassian.JIRA>
References: <JIRA.12781467.1543486357000@Atlassian.JIRA>
	<JIRA.12781467.1543486357000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781467.1543486357000.105205.1543496100441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Ondra Chaloupka created pull request #1387 in GitHub
----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Coding In Progress)


> InboundBridge recovery aborts live transactions
> -----------------------------------------------
>
>                 Key: JBTM-3079
>                 URL: https://issues.jboss.org/browse/JBTM-3079
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: TxBridge
>    Affects Versions: 5.5.32.Final, 5.9.0.Final
>         Environment: EAP 7.1.5 / 5.5.32.Final
>            Reporter: Jonathan Halliday
>            Assignee: Tom Jenkinson
>            Priority: Critical
>         Attachments: jbtm3079.patch
>
>
> During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
> TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) 
> TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > 
> ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
> It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 08:59:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 29 Nov 2018 08:59:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3074) No test cleanup for STM
	taxonomy tests
In-Reply-To: <JIRA.12777138.1540995420000@Atlassian.JIRA>
References: <JIRA.12777138.1540995420000@Atlassian.JIRA>
	<JIRA.12777138.1540995420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12777138.1540995420000.105783.1543499940531@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-3074:
-----------------------------------
    Component/s: STM


> No test cleanup for STM taxonomy tests 
> ---------------------------------------
>
>                 Key: JBTM-3074
>                 URL: https://issues.jboss.org/browse/JBTM-3074
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: STM
>            Reporter: Michael Musgrove
>            Priority: Major
>         Attachments: stm.dump
>
>
> The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 09:00:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 29 Nov 2018 09:00:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3074) No test cleanup for STM
	taxonomy tests
In-Reply-To: <JIRA.12777138.1540995420000@Atlassian.JIRA>
References: <JIRA.12777138.1540995420000@Atlassian.JIRA>
	<JIRA.12777138.1540995420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12777138.1540995420000.105786.1543500000247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove reassigned JBTM-3074:
--------------------------------------

    Assignee: Michael Musgrove


> No test cleanup for STM taxonomy tests 
> ---------------------------------------
>
>                 Key: JBTM-3074
>                 URL: https://issues.jboss.org/browse/JBTM-3074
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: STM
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>         Attachments: stm.dump
>
>
> The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu Nov 29 09:56:00 2018
From: issues at jboss.org (Martin Stefanko (Jira))
Date: Thu, 29 Nov 2018 09:56:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3082) Coordinator reports LRA
 as compensating when the participant is not able to finish complete method
 invocation immediately
In-Reply-To: <JIRA.12781540.1543503321000@Atlassian.JIRA>
References: <JIRA.12781540.1543503321000@Atlassian.JIRA>
	<JIRA.12781540.1543503321982@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781540.1543503321000.106149.1543503360195@Atlassian.JIRA>

Martin Stefanko created JBTM-3082:
-------------------------------------

             Summary: Coordinator reports LRA as compensating when the participant is not able to finish complete method invocation immediately
                 Key: JBTM-3082
                 URL: https://issues.jboss.org/browse/JBTM-3082
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.9.0.Final
            Reporter: Martin Stefanko
            Assignee: Michael Musgrove


If the participant cannot finish the complete method invocation immediately and thus returns 202 ACCEPTED return code and then somebody calls get status of the finishing LRA, the coordinator reports it as CompensatorStatus.Compensating instead of CompensatorStatus.Completing.

The status of the finishing LRA is changed to Compensating here [1] possibly because of this line [2] as heuristicList is not empty.

[1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L404
[2] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/LRARecord.java#L387



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 30 07:03:00 2018
From: issues at jboss.org (Jan-Willem Gmelig Meyling (Jira))
Date: Fri, 30 Nov 2018 07:03:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3083) Cannot get delegate of
 JMSContext during an beforeCompletion invocation
In-Reply-To: <JIRA.12781697.1543579375000@Atlassian.JIRA>
References: <JIRA.12781697.1543579375000@Atlassian.JIRA>
	<JIRA.12781697.1543579375282@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781697.1543579375000.112164.1543579380475@Atlassian.JIRA>

Jan-Willem Gmelig Meyling created JBTM-3083:
-----------------------------------------------

             Summary: Cannot get delegate of JMSContext during an beforeCompletion invocation
                 Key: JBTM-3083
                 URL: https://issues.jboss.org/browse/JBTM-3083
             Project: JBoss Transaction Manager
          Issue Type: Bug
         Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
WildFly 8.0.0.CR1
            Reporter: Jan-Willem Gmelig Meyling
         Attachments: ARJUNA016082.log

The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.

*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.

*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the pre-commit synchronization.

The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
(Which refers to WildFly 8.0.0.CR1)

Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.

See the attached log for a full stack trace.





--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 30 07:04:00 2018
From: issues at jboss.org (Jan-Willem Gmelig Meyling (Jira))
Date: Fri, 30 Nov 2018 07:04:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3083) Cannot get delegate of
 JMSContext during an beforeCompletion synch
In-Reply-To: <JIRA.12781697.1543579375000@Atlassian.JIRA>
References: <JIRA.12781697.1543579375000@Atlassian.JIRA>
	<JIRA.12781697.1543579375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781697.1543579375000.112167.1543579440369@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan-Willem Gmelig Meyling updated JBTM-3083:
--------------------------------------------
    Summary: Cannot get delegate of JMSContext during an beforeCompletion synch  (was: Cannot get delegate of JMSContext during an beforeCompletion invocation)


> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
>                 Key: JBTM-3083
>                 URL: https://issues.jboss.org/browse/JBTM-3083
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>         Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
>            Reporter: Jan-Willem Gmelig Meyling
>            Priority: Minor
>         Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the pre-commit synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 30 07:04:00 2018
From: issues at jboss.org (Jan-Willem Gmelig Meyling (Jira))
Date: Fri, 30 Nov 2018 07:04:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3083) Cannot get delegate of
 JMSContext during an beforeCompletion synch
In-Reply-To: <JIRA.12781697.1543579375000@Atlassian.JIRA>
References: <JIRA.12781697.1543579375000@Atlassian.JIRA>
	<JIRA.12781697.1543579375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781697.1543579375000.112179.1543579440711@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan-Willem Gmelig Meyling updated JBTM-3083:
--------------------------------------------
    Description: 
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.

*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.

*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.

The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
(Which refers to WildFly 8.0.0.CR1)

Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.

See the attached log for a full stack trace.



  was:
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.

*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.

*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the pre-commit synchronization.

The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
(Which refers to WildFly 8.0.0.CR1)

Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.

See the attached log for a full stack trace.





> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
>                 Key: JBTM-3083
>                 URL: https://issues.jboss.org/browse/JBTM-3083
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>         Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
>            Reporter: Jan-Willem Gmelig Meyling
>            Priority: Minor
>         Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 30 07:05:00 2018
From: issues at jboss.org (Jan-Willem Gmelig Meyling (Jira))
Date: Fri, 30 Nov 2018 07:05:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3083) Cannot get delegate of
 JMSContext during an beforeCompletion synch
In-Reply-To: <JIRA.12781697.1543579375000@Atlassian.JIRA>
References: <JIRA.12781697.1543579375000@Atlassian.JIRA>
	<JIRA.12781697.1543579375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12781697.1543579375000.112183.1543579500091@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan-Willem Gmelig Meyling updated JBTM-3083:
--------------------------------------------
    Description: 
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)

*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.

*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.

The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
(Which refers to WildFly 8.0.0.CR1)

Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.

See the attached log for a full stack trace.



  was:
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.

*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.

*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.

The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
(Which refers to WildFly 8.0.0.CR1)

Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.

See the attached log for a full stack trace.





> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
>                 Key: JBTM-3083
>                 URL: https://issues.jboss.org/browse/JBTM-3083
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>         Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
>            Reporter: Jan-Willem Gmelig Meyling
>            Priority: Minor
>         Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction  {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-synchronizations-are-not-allowed-when-sending-mess 
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization  should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri Nov 30 08:30:00 2018
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Fri, 30 Nov 2018 08:30:00 -0500 (EST)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3074) No test cleanup for STM
	taxonomy tests
In-Reply-To: <JIRA.12777138.1540995420000@Atlassian.JIRA>
References: <JIRA.12777138.1540995420000@Atlassian.JIRA>
	<JIRA.12777138.1540995420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12777138.1540995420000.113004.1543584600855@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Michael Musgrove created pull request #1389 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> No test cleanup for STM taxonomy tests 
> ---------------------------------------
>
>                 Key: JBTM-3074
>                 URL: https://issues.jboss.org/browse/JBTM-3074
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: STM
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>         Attachments: stm.dump
>
>
> The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)