From issues at jboss.org  Tue May  1 09:12:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 1 May 2018 09:12:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3018) Migrate the LRA
 implementation to use the microprofile-lra API
In-Reply-To: <JIRA.12747935.1525180281000@Atlassian.JIRA>
References: <JIRA.12747935.1525180281000@Atlassian.JIRA>
	<JIRA.12747935.1525180281571@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747935.1525180281000.132413.1525180320289@Atlassian.JIRA>

Michael Musgrove created JBTM-3018:
--------------------------------------

             Summary: 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
             Fix For: 5.later


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.5.0#75005)

From issues at jboss.org  Wed May  2 01:42:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Wed, 2 May 2018 01:42:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3015) Tomcat JTA: Race
 condition in tx recovery makes PeriodicRecovery run forever
In-Reply-To: <JIRA.12746790.1524575227000@Atlassian.JIRA>
References: <JIRA.12746790.1524575227000@Atlassian.JIRA>
	<JIRA.12746790.1524575227000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12746790.1524575227000.135711.1525239720115@Atlassian.JIRA>


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

Amos Feng updated JBTM-3015:
----------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Tomcat JTA: Race condition in tx recovery makes PeriodicRecovery run forever
> ----------------------------------------------------------------------------
>
>                 Key: JBTM-3015
>                 URL: https://issues.jboss.org/browse/JBTM-3015
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>         Environment: Oracle JDK 8, Linux, 8 CPU system
>            Reporter: Michal Karm Babacek
>            Assignee: Amos Feng
>            Priority: Critical
>             Fix For: 5.next
>
>         Attachments: good_threaddumps.zip, postgresql_trace_log.zip, test.war, thread_dumps_in_sequence_over_time.zip, tomcat_logs.zip
>
>
> There is a simple [recovery test in the test suite|https://github.com/jbosstm/narayana/blob/master/tomcat/tomcat-jta/src/test/java/org/jboss/narayana/tomcat/jta/integration/BaseITCase.java#L141] that runs 3 times in a row. If you change that number to 4, there is a good change you will get the TS stuck forever. When I attached debugger and used breakpoints on the iteration, e.g. {{i==3}} or {{i==10}}, the error was not shown, the TS run and completed, so it is clearly a time related race condition.
> *EDIT:* When I use 30 iterations and a conditional breakpoint on {{i -> test(EXECUTOR_URL + RECOVERY_TEST)}} set to {{i == 28}} the execution loops forever even with debugger attached.
> In this JIRA's example, to reproduce, simply:
> {noformat}
> -        IntStream.range(0, 3).forEach(i -> test(EXECUTOR_URL + RECOVERY_TEST));
> +        IntStream.range(0, 10).forEach(i -> test(EXECUTOR_URL + RECOVERY_TEST));
> {noformat}
> When the Tomcat gets into this unfortunate state and TS hangs and Tomcat runs forever, this is what keeps showing in the database trace (and nothing else):
> {noformat}
> ...
> 2018-04-24 12:37:50.406 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:37:54.410 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:37:58.415 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:02.419 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:06.421 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:10.423 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:14.426 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:18.429 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> ...
> {noformat}
> I found this Atomikos related reference [online|https://fogbugz.atomikos.com/default13dd.html?community.6.3576.0].
> Tomcat log keeps showing again and again:
> {noformat}
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread Status <== SCANNING
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread scanning
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal Periodic recovery first pass at Tue, 24 Apr 2018 14:41:02
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkFirstPass AtomicActionRecoveryModule first pass
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactions processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change IDLE->FIRST_PASS
> 24-Apr-2018 14:41:02.538 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass Local XARecoveryModule - first pass
> 24-Apr-2018 14:41:02.538 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass xarecovery of org.postgresql.xa.PGXAConnection at 2c8cb5bd
> 24-Apr-2018 14:41:02.538 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass Found 0 xids in doubt
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass xarecovery of org.jboss.narayana.tomcat.jta.integration.app.TestXAResource at 4094781e
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass Found 0 xids in doubt
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change FIRST_PASS->BETWEEN_PASSES
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal Periodic recovery second pass at Tue, 24 Apr 2018 14:41:04
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass AtomicActionRecoveryModule second pass
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass Local XARecoveryModule - second pass
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass Local XARecoveryModule.transactionInitiatedRecovery completed
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass xarecovery second pass of org.postgresql.xa.PGXAConnection at 2c8cb5bd
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass Have 0 Xids to recover on this pass.
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass xarecovery second pass of org.jboss.narayana.tomcat.jta.integration.app.TestXAResource at 4094781e
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass Have 0 Xids to recover on this pass.
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass Local XARecoveryModule.resourceInitiatedRecovery completed
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change SECOND_PASS->IDLE
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread Status <== INACTIVE
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread backing off
> {noformat} 
> h3. Logs and thread dumps
> * [^postgresql_trace_log.zip] -- PostgreSQL trace, note the originally expected course of recoveries and then the repeated stuck on the aforementioned message.
> * [^test.war] -- test app used; the TS builds it for you though and stores it in {{tomcat/tomcat-deployment/_DEFAULT__Basic-app_test.war}}
> * [^thread_dumps_in_sequence_over_time.zip] -- thread dumps taken over time with minutes in between snaps.
> * [^tomcat_logs.zip] -- Tomcat logs
> * [^good_threaddumps.zip] --  a dozen of snapshots couple of seconds from each other as an example of a good TS run that terminates as expected, i.e. with {{IntStream.range(0, 3).forEach(i -> test(EXECUTOR_URL + RECOVERY_TEST));}}.
> * This is what good, i.e. 3 iterations long DB trace looks like: [good db trace|https://paste.fedoraproject.org/paste/drANRRl4DlckwLhSIwCOdA/raw].
> * This is what good, i.e. 3 iterations long Tomcat catalina log looks like:  [catalina log|https://paste.fedoraproject.org/paste/CkaDCZCtoVhDtyTglEOFqg/raw]
> Might interest also [~ochaloup].   WDYT guys? What should I try out?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May  3 02:45:00 2018
From: issues at jboss.org (Michal Karm Babacek (JIRA))
Date: Thu, 3 May 2018 02:45:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3019) Testsuite: Docker
 controller leaves stray volumes and fills up disk space unnecessairly over
 time
In-Reply-To: <JIRA.12748357.1525329872000@Atlassian.JIRA>
References: <JIRA.12748357.1525329872000@Atlassian.JIRA>
	<JIRA.12748357.1525329872852@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12748357.1525329872000.144076.1525329900544@Atlassian.JIRA>

Michal Karm Babacek created JBTM-3019:
-----------------------------------------

             Summary: Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time
                 Key: JBTM-3019
                 URL: https://issues.jboss.org/browse/JBTM-3019
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Testing
    Affects Versions: 5.8.1.Final
         Environment: Docker enabled Jenkins slaves
            Reporter: Michal Karm Babacek
            Assignee: Michal Karm Babacek
            Priority: Minor
             Fix For: 5.next


h3. Problem
The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images:
{code}
[root at karm-centos7-x86-64 ~]# docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
docker.io/postgres   9.4                 26bd9b04b948        6 days ago          232 MB
docker.io/postgres   10                  0965cdc98045        6 days ago          234 MB
docker.io/postgres   <none>              ed5db6e669ff        7 weeks ago         263 MB
docker.io/postgres   <none>              30121e967865        7 weeks ago         289 MB
[root at karm-centos7-x86-64 ~]# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root at karm-centos7-x86-64 ~]# 
{code}
Although it leaves stray container volumes for some reason:
{code}
[root at karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes
15G	/var/lib/docker-latest/volumes
[root at karm-centos7-x86-64 ~]# docker volume ls -qf dangling=true | wc -l
409
{code}
It unnecessarily clogs the slaves' disk space. The 15G of garbage has been created over dozens and dozens of builds with at least two containers each, but it shouldn't be happening anyway.

h3. Call to action
Review whether [removeContainerCmd|https://github.com/jbosstm/narayana/blob/master/tools/src/main/java/io/narayana/db/PostgreContainerAllocator.java#L264] is supposed to be enough to not only remove the container but to also remove its volume.

h3. Workaround
{code}
docker volume prune
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May  3 09:33:03 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 3 May 2018 09:33:03 -0400 (EDT)
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.147877.1525354383142@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 #1308 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> 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
>             Fix For: 5.later
>
>
> 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.5.0#75005)

From issues at jboss.org  Thu May  3 09:33:03 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 3 May 2018 09:33:03 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3016) NoSuchFieldException
 throws when setting the pool properties
In-Reply-To: <JIRA.12747153.1524729045000@Atlassian.JIRA>
References: <JIRA.12747153.1524729045000@Atlassian.JIRA>
	<JIRA.12747153.1524729045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747153.1524729045000.147879.1525354383193@Atlassian.JIRA>


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

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


> NoSuchFieldException throws when setting the pool properties
> ------------------------------------------------------------
>
>                 Key: JBTM-3016
>                 URL: https://issues.jboss.org/browse/JBTM-3016
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May  4 04:14:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 4 May 2018 04:14:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3016) NoSuchFieldException
 throws when setting the pool properties
In-Reply-To: <JIRA.12747153.1524729045000@Atlassian.JIRA>
References: <JIRA.12747153.1524729045000@Atlassian.JIRA>
	<JIRA.12747153.1524729045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747153.1524729045000.153415.1525421640201@Atlassian.JIRA>


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

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


> NoSuchFieldException throws when setting the pool properties
> ------------------------------------------------------------
>
>                 Key: JBTM-3016
>                 URL: https://issues.jboss.org/browse/JBTM-3016
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May  9 03:52:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Wed, 9 May 2018 03:52:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3016) NoSuchFieldException
 throws when setting the pool properties
In-Reply-To: <JIRA.12747153.1524729045000@Atlassian.JIRA>
References: <JIRA.12747153.1524729045000@Atlassian.JIRA>
	<JIRA.12747153.1524729045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747153.1524729045000.172779.1525852320192@Atlassian.JIRA>


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

Amos Feng reopened JBTM-3016:
-----------------------------


I have to reopen this issue to update to use the BasicManagedDataSource

> NoSuchFieldException throws when setting the pool properties
> ------------------------------------------------------------
>
>                 Key: JBTM-3016
>                 URL: https://issues.jboss.org/browse/JBTM-3016
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 10 08:05:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 10 May 2018 08:05:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3016) NoSuchFieldException
 throws when setting the pool properties
In-Reply-To: <JIRA.12747153.1524729045000@Atlassian.JIRA>
References: <JIRA.12747153.1524729045000@Atlassian.JIRA>
	<JIRA.12747153.1524729045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747153.1524729045000.183657.1525953900117@Atlassian.JIRA>


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

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


> NoSuchFieldException throws when setting the pool properties
> ------------------------------------------------------------
>
>                 Key: JBTM-3016
>                 URL: https://issues.jboss.org/browse/JBTM-3016
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May 11 11:23:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 11 May 2018 11:23:00 -0400 (EDT)
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.1526052127123@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749718.1526052127000.192273.1526052180090@Atlassian.JIRA>

David Lloyd created JBTM-3020:
---------------------------------

             Summary: 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


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.

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.5.0#75005)

From issues at jboss.org  Fri May 11 11:25:01 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 11 May 2018 11:25:01 -0400 (EDT)
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.192280.1526052301133@Atlassian.JIRA>


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

Tom Jenkinson reassigned JBTM-3020:
-----------------------------------

    Assignee: Ondra Chaloupka


> 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
>             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.
> 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.5.0#75005)

From issues at jboss.org  Fri May 11 11:25:01 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 11 May 2018 11:25:01 -0400 (EDT)
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.192283.1526052301204@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-3020:
--------------------------------
    Fix Version/s: 5.next


> 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
>             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.
> 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.5.0#75005)

From issues at jboss.org  Fri May 11 11:42:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 11 May 2018 11:42:00 -0400 (EDT)
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.192348.1526053320859@Atlassian.JIRA>


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

David Lloyd updated JBTM-3020:
------------------------------
    Description: 
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.

  was:
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.

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.



> 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
>             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.5.0#75005)

From issues at jboss.org  Mon May 14 08:44:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 14 May 2018 08:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion
 from reaper thread can get ConcurrentModificationException
In-Reply-To: <JIRA.12749927.1526301809000@Atlassian.JIRA>
References: <JIRA.12749927.1526301809000@Atlassian.JIRA>
	<JIRA.12749927.1526301809721@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749927.1526301809000.5871.1526301840518@Atlassian.JIRA>

Tom Jenkinson created JBTM-3021:
-----------------------------------

             Summary: Running afterCompletion from reaper thread can get ConcurrentModificationException
                 Key: JBTM-3021
                 URL: https://issues.jboss.org/browse/JBTM-3021
             Project: JBoss Transaction Manager
          Issue Type: Bug
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson


The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 14 08:44:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 14 May 2018 08:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion
 from reaper thread can get ConcurrentModificationException
In-Reply-To: <JIRA.12749927.1526301810000@Atlassian.JIRA>
References: <JIRA.12749927.1526301810000@Atlassian.JIRA>
	<JIRA.12749927.1526301810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749927.1526301810000.5873.1526301840566@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-3021:
--------------------------------
    Reporter: Amos Feng  (was: Tom Jenkinson)


> Running afterCompletion from reaper thread can get ConcurrentModificationException
> ----------------------------------------------------------------------------------
>
>                 Key: JBTM-3021
>                 URL: https://issues.jboss.org/browse/JBTM-3021
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Tom Jenkinson
>
> The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 15 04:20:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 15 May 2018 04:20:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion
 from reaper thread can get ConcurrentModificationException
In-Reply-To: <JIRA.12749927.1526301810000@Atlassian.JIRA>
References: <JIRA.12749927.1526301810000@Atlassian.JIRA>
	<JIRA.12749927.1526301810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749927.1526301810000.12626.1526372400223@Atlassian.JIRA>


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

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


> Running afterCompletion from reaper thread can get ConcurrentModificationException
> ----------------------------------------------------------------------------------
>
>                 Key: JBTM-3021
>                 URL: https://issues.jboss.org/browse/JBTM-3021
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Tom Jenkinson
>
> The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 15 04:38:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 15 May 2018 04:38:00 -0400 (EDT)
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.12804.1526373480546@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-3020:
--------------------------------
    Forum Reference: https://developer.jboss.org/message/982097, https://javaee.groups.io/g/jta-spec/topic/suggestion_for_a_2pc/18102512  (was: https://developer.jboss.org/message/982097)


> 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
>             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.5.0#75005)

From issues at jboss.org  Tue May 15 15:08:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 15 May 2018 15:08:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion
 from reaper thread can get ConcurrentModificationException
In-Reply-To: <JIRA.12749927.1526301810000@Atlassian.JIRA>
References: <JIRA.12749927.1526301810000@Atlassian.JIRA>
	<JIRA.12749927.1526301810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749927.1526301810000.7195.1526411280112@Atlassian.JIRA>


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

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


> Running afterCompletion from reaper thread can get ConcurrentModificationException
> ----------------------------------------------------------------------------------
>
>                 Key: JBTM-3021
>                 URL: https://issues.jboss.org/browse/JBTM-3021
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Tom Jenkinson
>
> The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 15 15:08:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 15 May 2018 15:08:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion
 from reaper thread can get ConcurrentModificationException
In-Reply-To: <JIRA.12749927.1526301810000@Atlassian.JIRA>
References: <JIRA.12749927.1526301810000@Atlassian.JIRA>
	<JIRA.12749927.1526301810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12749927.1526301810000.7198.1526411280194@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-3021:
--------------------------------
    Component/s: JTA


> Running afterCompletion from reaper thread can get ConcurrentModificationException
> ----------------------------------------------------------------------------------
>
>                 Key: JBTM-3021
>                 URL: https://issues.jboss.org/browse/JBTM-3021
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTA
>            Reporter: Amos Feng
>            Assignee: Tom Jenkinson
>
> The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 16 03:01:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Wed, 16 May 2018 03:01:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3016) NoSuchFieldException
 throws when setting the pool properties
In-Reply-To: <JIRA.12747153.1524729045000@Atlassian.JIRA>
References: <JIRA.12747153.1524729045000@Atlassian.JIRA>
	<JIRA.12747153.1524729045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747153.1524729045000.9172.1526454060528@Atlassian.JIRA>


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

Amos Feng updated JBTM-3016:
----------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> NoSuchFieldException throws when setting the pool properties
> ------------------------------------------------------------
>
>                 Key: JBTM-3016
>                 URL: https://issues.jboss.org/browse/JBTM-3016
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 16 04:53:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 16 May 2018 04:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3022) The build should build
 the (deprecated) lra-annotations module
In-Reply-To: <JIRA.12750455.1526460727000@Atlassian.JIRA>
References: <JIRA.12750455.1526460727000@Atlassian.JIRA>
	<JIRA.12750455.1526460727535@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12750455.1526460727000.10470.1526460780094@Atlassian.JIRA>

Michael Musgrove created JBTM-3022:
--------------------------------------

             Summary: The build should build the (deprecated) lra-annotations module
                 Key: JBTM-3022
                 URL: https://issues.jboss.org/browse/JBTM-3022
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.8.1.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


the lra parent pom should include a build of the lra-annotations module:

<module>lra-annotations</module>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 16 05:59:01 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 16 May 2018 05:59:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3022) The build should build
 the (deprecated) lra-annotations module
In-Reply-To: <JIRA.12750455.1526460728000@Atlassian.JIRA>
References: <JIRA.12750455.1526460728000@Atlassian.JIRA>
	<JIRA.12750455.1526460728000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12750455.1526460728000.11283.1526464741224@Atlassian.JIRA>


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

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


> The build should build the (deprecated) lra-annotations module
> --------------------------------------------------------------
>
>                 Key: JBTM-3022
>                 URL: https://issues.jboss.org/browse/JBTM-3022
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> the lra parent pom should include a build of the lra-annotations module:
> <module>lra-annotations</module>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 17 04:28:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 17 May 2018 04:28:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3022) The build should build
 the (deprecated) lra-annotations module
In-Reply-To: <JIRA.12750455.1526460728000@Atlassian.JIRA>
References: <JIRA.12750455.1526460728000@Atlassian.JIRA>
	<JIRA.12750455.1526460728000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12750455.1526460728000.20069.1526545680779@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-3022:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> The build should build the (deprecated) lra-annotations module
> --------------------------------------------------------------
>
>                 Key: JBTM-3022
>                 URL: https://issues.jboss.org/browse/JBTM-3022
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> the lra parent pom should include a build of the lra-annotations module:
> <module>lra-annotations</module>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May 18 03:21:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 18 May 2018 03:21:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2945) Track SRAs that are
 started in the context of an LRA
In-Reply-To: <JIRA.12716653.1508180914000@Atlassian.JIRA>
References: <JIRA.12716653.1508180914000@Atlassian.JIRA>
	<JIRA.12716653.1508180914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716653.1508180914000.27769.1526628060828@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2945:
-----------------------------------
    Fix Version/s: 6.later
                       (was: 5.later)


> Track SRAs that are started in the context of an LRA
> ----------------------------------------------------
>
>                 Key: JBTM-2945
>                 URL: https://issues.jboss.org/browse/JBTM-2945
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: LRA
>    Affects Versions: 5.7.0.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 6.later
>
>
> Often an LRA is built up from a number of individual actions performed by the
> participants enlisted with the LRA. These participants may use the ACID
> guarantees that an SRA provides in order to fulfil the requisite compensatory
> and completion actions when the LRA is terminated. To support this requirement
> when an SRA is started in the context of an LRA (either by annotating a method
> with both the @LRA and @SRA annotations or by starting an SRA via the client
> API when an LRA is already active) then the SRA will be automatically
> associated with the LRA. The following interface is provided for querying which
> LRAs and SRAs are associated with each other (in a one to many relationship):
> {code}
> public interface LRAToSRA {
>   /**
>    * return all the SRAs running in the context of the given LRA
>    */
>   List<SRA> getAssociatedSRAs(URL lraId};
>   /**
>    * see if an LRA is associated with the give SRA
>    */
>   URL getAssociatedLRA(URL sraId);
> }
> {code}
> Questions:
>    - should @Compensate and @Complete block until all associated SRAs have finished
>    - when an LRA is closed or cancelled should any active SRAs be automatically be committed or rolled back.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May 18 03:38:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 18 May 2018 03:38:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2957) LRA specification:
 descriptions for start/end and LRA do not say which response codes are
 valid
In-Reply-To: <JIRA.12720762.1510573204000@Atlassian.JIRA>
References: <JIRA.12720762.1510573204000@Atlassian.JIRA>
	<JIRA.12720762.1510573204000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720762.1510573204000.27807.1526629080620@Atlassian.JIRA>


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

Michael Musgrove closed JBTM-2957.
----------------------------------
    Resolution: Rejected


This JIRA related to the interoperability part of the spec that  defined the protocol in terms of REST endpoints and REST request/responses but interoperability has now been dropped so this JIRA is no longer applicable.

Note that that the @LRA annotation controls the starting and ending of an LRA so if asynchronous operations were supported the user would just need to mark his/her resource methods with @Asynchronous.

Also note that the LRAClient API start, close and cancel methods can throw  GenericLRAException which exposes a getStatusCode() method for reporting HTTP status codes.

> LRA specification: descriptions for start/end and LRA do not say which response codes are valid
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2957
>                 URL: https://issues.jboss.org/browse/JBTM-2957
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are:
> > Performing a `POST` on ... creates an LRA.
> > Performing a `PUT` on .../close will trigger the successful completion of the LRA ...
> This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment).
> The proposal (and reference implementation) should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted"



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat May 19 12:46:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 May 2018 12:46:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2958) Wrong format of the Link
 header on joining LRA by participant should return error to the participant
In-Reply-To: <JIRA.12720763.1510573335000@Atlassian.JIRA>
References: <JIRA.12720763.1510573335000@Atlassian.JIRA>
	<JIRA.12720763.1510573335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720763.1510573335000.33638.1526748360124@Atlassian.JIRA>


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

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


> Wrong format of the Link header on joining LRA by participant should return error to the participant
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2958
>                 URL: https://issues.jboss.org/browse/JBTM-2958
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>            Reporter: Ondra Chaloupka
>            Assignee: Michael Musgrove
>
> If there is a participant joining a started LRA which uses wrong format of {{Link}} header then {{NullPointer}} is logged to the swarm server log. But client gets status {{OK}}.
> Client should be informed that enlistment failed and there should not be nullpointer in the log.
> NullPointer
> {code}
> INFO  [io.narayana.lra] (default task-4) Cannot extract compensator from link'http://localhost': java.lang.IllegalArgumentException: RESTEASY003960: Unable to parse Link header.  No end to parameter: http://localhost
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parseAttribute(LinkDelegate.java:112)
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parse(LinkDelegate.java:63)
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:160)
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:23)
>         at org.jboss.resteasy.specimpl.LinkImpl.valueOf(LinkImpl.java:31)
>         at org.jboss.resteasy.specimpl.LinkBuilderImpl.link(LinkBuilderImpl.java:34)
>         at javax.ws.rs.core.Link.valueOf(Link.java:173)
>         at io.narayana.lra.coordinator.domain.model.LRARecord.extractCompensator(LRARecord.java:150)
>         at io.narayana.lra.coordinator.domain.model.Transaction.findLRAParticipant(Transaction.java:498)
>         at io.narayana.lra.coordinator.domain.model.Transaction.enlistParticipant(Transaction.java:428)
>         at io.narayana.lra.coordinator.domain.service.LRAService.joinLRA(LRAService.java:268)
>         at io.narayana.lra.coordinator.domain.service.LRAService$Proxy$_$$_WeldClientProxy.joinLRA(Unknown Source)
>         at io.narayana.lra.coordinator.api.Coordinator.joinLRA(Coordinator.java:468)
>         at io.narayana.lra.coordinator.api.Coordinator.joinLRAViaBody(Coordinator.java:406)
>         at io.narayana.lra.coordinator.api.Coordinator$Proxy$_$$_WeldClientProxy.joinLRAViaBody(Unknown Source)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
>         at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:62)
>         at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>         at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>         at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>         at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>         at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>         at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>         at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>         at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> {code}
> The ok return code:
> {code}
> curl -i -X PUT -H "Link: http://localhost" http://localhost:8080/lra-coordinator/0_ffff0a000007_-39bdc3dc_5a098390_d
> HTTP/1.1 200 OK
> Connection: keep-alive
> Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11
> Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11
> Content-Type: application/json
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat May 19 12:46:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 May 2018 12:46:00 -0400 (EDT)
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.33640.1526748360173@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-3018:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> 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
>             Fix For: 5.later
>
>
> 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.5.0#75005)

From issues at jboss.org  Sat May 19 12:47:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 May 2018 12:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2959) Allow different LRA
 coordinators to share an object store
In-Reply-To: <JIRA.12720824.1510589555000@Atlassian.JIRA>
References: <JIRA.12720824.1510589555000@Atlassian.JIRA>
	<JIRA.12720824.1510589555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720824.1510589555000.33642.1526748420078@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2959:
-----------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/jbosstm/narayana/pull/1317


> Allow different LRA coordinators to share an object store
> ---------------------------------------------------------
>
>                 Key: JBTM-2959
>                 URL: https://issues.jboss.org/browse/JBTM-2959
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go.
> If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes.
> Some notes on the current implementation:
> # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent).
> # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place).
> # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user.
> # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery.
> # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages").



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat May 19 12:50:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 May 2018 12:50:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2959) Allow different LRA
 coordinators to share an object store
In-Reply-To: <JIRA.12720824.1510589555000@Atlassian.JIRA>
References: <JIRA.12720824.1510589555000@Atlassian.JIRA>
	<JIRA.12720824.1510589555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720824.1510589555000.33645.1526748600156@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2959:
-----------------------------------
    Git Pull Request:   (was: https://github.com/jbosstm/narayana/pull/1317)


> Allow different LRA coordinators to share an object store
> ---------------------------------------------------------
>
>                 Key: JBTM-2959
>                 URL: https://issues.jboss.org/browse/JBTM-2959
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go.
> If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes.
> Some notes on the current implementation:
> # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent).
> # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place).
> # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user.
> # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery.
> # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages").



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat May 19 12:53:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 May 2018 12:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2959) Allow different LRA
 coordinators to share an object store
In-Reply-To: <JIRA.12720824.1510589555000@Atlassian.JIRA>
References: <JIRA.12720824.1510589555000@Atlassian.JIRA>
	<JIRA.12720824.1510589555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720824.1510589555000.33647.1526748780089@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2959:
-----------------------------------
    Status: Open  (was: Pull Request Sent)


> Allow different LRA coordinators to share an object store
> ---------------------------------------------------------
>
>                 Key: JBTM-2959
>                 URL: https://issues.jboss.org/browse/JBTM-2959
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go.
> If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes.
> Some notes on the current implementation:
> # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent).
> # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place).
> # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user.
> # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery.
> # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages").



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat May 19 12:58:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 May 2018 12:58:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation
In-Reply-To: <JIRA.12711604.1505314280000@Atlassian.JIRA>
References: <JIRA.12711604.1505314280000@Atlassian.JIRA>
	<JIRA.12711604.1505314280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12711604.1505314280000.33651.1526749080203@Atlassian.JIRA>


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

Michael Musgrove resolved JBTM-2929.
------------------------------------
    Resolution: Done


The documentation is maintained in the microprofile-lra repo at:
[https://github.com/jbosstm/microprofile-lra/blob/microprofile-lra/spec/src/main/asciidoc/microprofile-lra-spec.adoc|http://example.com]
which in turn will be pushed to the [https://github.com/eclipse/microprofile-lra|http://example.com] repo

> Create LRA documentation
> ------------------------
>
>                 Key: JBTM-2929
>                 URL: https://issues.jboss.org/browse/JBTM-2929
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Documentation, LRA
>    Affects Versions: 5.6.4.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> Add LRA documentation. 
> The documentation is intended to be a MicroProfile specification and is available in the sandbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun May 20 05:15:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sun, 20 May 2018 05:15:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2978) Compensation should not
 be considered done in case of network error
In-Reply-To: <JIRA.12725963.1513939207000@Atlassian.JIRA>
References: <JIRA.12725963.1513939207000@Atlassian.JIRA>
	<JIRA.12725963.1513939207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725963.1513939207000.33742.1526807700157@Atlassian.JIRA>


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

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


> Compensation should not be considered done in case of network error
> -------------------------------------------------------------------
>
>                 Key: JBTM-2978
>                 URL: https://issues.jboss.org/browse/JBTM-2978
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Nicola Ferraro
>            Assignee: Michael Musgrove
>
> In case of network error on the call to "/compensate" made by the coordinator to the participant, the LRA is considered compensated, hence the compensate action is not retried again. This is not the expected behavior.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun May 20 12:50:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sun, 20 May 2018 12:50:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2977) Participants should not
 be told to compensate after completion
In-Reply-To: <JIRA.12725953.1513933458000@Atlassian.JIRA>
References: <JIRA.12725953.1513933458000@Atlassian.JIRA>
	<JIRA.12725953.1513933458000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725953.1513933458000.33822.1526835000147@Atlassian.JIRA>


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

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


> Participants should not be told to compensate after completion
> --------------------------------------------------------------
>
>                 Key: JBTM-2977
>                 URL: https://issues.jboss.org/browse/JBTM-2977
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Nicola Ferraro
>            Assignee: Michael Musgrove
>
> When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond.
> While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed.
> The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case).
> A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time.
> I attach few simple steps to reproduce it with shell commands.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun May 20 13:26:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Sun, 20 May 2018 13:26:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant
 completion calls during recovery do not timeout
In-Reply-To: <JIRA.12728045.1516028413000@Atlassian.JIRA>
References: <JIRA.12728045.1516028413000@Atlassian.JIRA>
	<JIRA.12728045.1516028413000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12728045.1516028413000.33840.1526837160096@Atlassian.JIRA>


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

Michael Musgrove commented on JBTM-2982:
----------------------------------------

This recovery part of this issue is fixed by JBTM-2977.

> LRA participant completion calls during recovery do not timeout
> ---------------------------------------------------------------
>
>                 Key: JBTM-2982
>                 URL: https://issues.jboss.org/browse/JBTM-2982
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>
> Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests).
> The issue also blocks the ability to shutdown the server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 06:49:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 06:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3023) Add a test to show
 compensations being retried after a network error
In-Reply-To: <JIRA.12751200.1526899717000@Atlassian.JIRA>
References: <JIRA.12751200.1526899717000@Atlassian.JIRA>
	<JIRA.12751200.1526899717354@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751200.1526899717000.35983.1526899740305@Atlassian.JIRA>

Michael Musgrove created JBTM-3023:
--------------------------------------

             Summary: Add a test to show compensations being retried after a network error
                 Key: JBTM-3023
                 URL: https://issues.jboss.org/browse/JBTM-3023
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: LRA
    Affects Versions: 5.8.1.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.later


The fix for JBTM-2978 (Compensation should not be considered done in case of network error) needs an automated test.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 07:07:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 07:07:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3024) Make sure build.sh builds
 the microprofile-lra artifacts
In-Reply-To: <JIRA.12751204.1526900795000@Atlassian.JIRA>
References: <JIRA.12751204.1526900795000@Atlassian.JIRA>
	<JIRA.12751204.1526900795428@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751204.1526900795000.36103.1526900820334@Atlassian.JIRA>

Michael Musgrove created JBTM-3024:
--------------------------------------

             Summary: Make sure build.sh builds the microprofile-lra artifacts
                 Key: JBTM-3024
                 URL: https://issues.jboss.org/browse/JBTM-3024
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: Build System
    Affects Versions: 5.8.1.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


The lra subsystem depends on the microprofile-lra artifacts which are in a separate repo. build.sh and build.bat need build these dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 07:18:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 07:18:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3024) Make sure top level
 README says how to build the eclipse microprofile-lra artifacts
In-Reply-To: <JIRA.12751204.1526900795000@Atlassian.JIRA>
References: <JIRA.12751204.1526900795000@Atlassian.JIRA>
	<JIRA.12751204.1526900795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751204.1526900795000.36306.1526901480369@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-3024:
-----------------------------------
    Summary: Make sure top level README says how to build the eclipse microprofile-lra artifacts  (was: Make sure build.sh builds the microprofile-lra artifacts)


> Make sure top level README says how to build the eclipse microprofile-lra artifacts
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-3024
>                 URL: https://issues.jboss.org/browse/JBTM-3024
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> The lra subsystem depends on the microprofile-lra artifacts which are in a separate repo. build.sh and build.bat need build these dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 07:37:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 07:37:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3024) Make sure top level
 README says how to build the eclipse microprofile-lra artifacts
In-Reply-To: <JIRA.12751204.1526900795000@Atlassian.JIRA>
References: <JIRA.12751204.1526900795000@Atlassian.JIRA>
	<JIRA.12751204.1526900795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751204.1526900795000.36536.1526902620472@Atlassian.JIRA>


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

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


> Make sure top level README says how to build the eclipse microprofile-lra artifacts
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-3024
>                 URL: https://issues.jboss.org/browse/JBTM-3024
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> The lra subsystem depends on the microprofile-lra artifacts which are in a separate repo. build.sh and build.bat need build these dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 07:41:01 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 07:41:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2958) Wrong format of the Link
 header on joining LRA by participant should return error to the participant
In-Reply-To: <JIRA.12720763.1510573335000@Atlassian.JIRA>
References: <JIRA.12720763.1510573335000@Atlassian.JIRA>
	<JIRA.12720763.1510573335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720763.1510573335000.36588.1526902861591@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2958:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Wrong format of the Link header on joining LRA by participant should return error to the participant
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2958
>                 URL: https://issues.jboss.org/browse/JBTM-2958
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>            Reporter: Ondra Chaloupka
>            Assignee: Michael Musgrove
>
> If there is a participant joining a started LRA which uses wrong format of {{Link}} header then {{NullPointer}} is logged to the swarm server log. But client gets status {{OK}}.
> Client should be informed that enlistment failed and there should not be nullpointer in the log.
> NullPointer
> {code}
> INFO  [io.narayana.lra] (default task-4) Cannot extract compensator from link'http://localhost': java.lang.IllegalArgumentException: RESTEASY003960: Unable to parse Link header.  No end to parameter: http://localhost
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parseAttribute(LinkDelegate.java:112)
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parse(LinkDelegate.java:63)
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:160)
>         at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:23)
>         at org.jboss.resteasy.specimpl.LinkImpl.valueOf(LinkImpl.java:31)
>         at org.jboss.resteasy.specimpl.LinkBuilderImpl.link(LinkBuilderImpl.java:34)
>         at javax.ws.rs.core.Link.valueOf(Link.java:173)
>         at io.narayana.lra.coordinator.domain.model.LRARecord.extractCompensator(LRARecord.java:150)
>         at io.narayana.lra.coordinator.domain.model.Transaction.findLRAParticipant(Transaction.java:498)
>         at io.narayana.lra.coordinator.domain.model.Transaction.enlistParticipant(Transaction.java:428)
>         at io.narayana.lra.coordinator.domain.service.LRAService.joinLRA(LRAService.java:268)
>         at io.narayana.lra.coordinator.domain.service.LRAService$Proxy$_$$_WeldClientProxy.joinLRA(Unknown Source)
>         at io.narayana.lra.coordinator.api.Coordinator.joinLRA(Coordinator.java:468)
>         at io.narayana.lra.coordinator.api.Coordinator.joinLRAViaBody(Coordinator.java:406)
>         at io.narayana.lra.coordinator.api.Coordinator$Proxy$_$$_WeldClientProxy.joinLRAViaBody(Unknown Source)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
>         at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:62)
>         at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>         at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>         at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>         at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>         at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>         at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>         at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>         at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> {code}
> The ok return code:
> {code}
> curl -i -X PUT -H "Link: http://localhost" http://localhost:8080/lra-coordinator/0_ffff0a000007_-39bdc3dc_5a098390_d
> HTTP/1.1 200 OK
> Connection: keep-alive
> Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11
> Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11
> Content-Type: application/json
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 07:53:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 07:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3023) Add a test to show
 compensations being retried after a network error
In-Reply-To: <JIRA.12751200.1526899717000@Atlassian.JIRA>
References: <JIRA.12751200.1526899717000@Atlassian.JIRA>
	<JIRA.12751200.1526899717000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751200.1526899717000.36751.1526903580823@Atlassian.JIRA>


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

Michael Musgrove closed JBTM-3023.
----------------------------------
    Resolution: Rejected


Will fix as part of https://issues.jboss.org/browse/JBTM-2978 instead

> Add a test to show compensations being retried after a network error
> --------------------------------------------------------------------
>
>                 Key: JBTM-3023
>                 URL: https://issues.jboss.org/browse/JBTM-3023
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: LRA
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> The fix for JBTM-2978 (Compensation should not be considered done in case of network error) needs an automated test.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon May 21 09:38:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 21 May 2018 09:38:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3024) Make sure top level
 README says how to build the eclipse microprofile-lra artifacts
In-Reply-To: <JIRA.12751204.1526900795000@Atlassian.JIRA>
References: <JIRA.12751204.1526900795000@Atlassian.JIRA>
	<JIRA.12751204.1526900795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751204.1526900795000.37878.1526909880314@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-3024:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Make sure top level README says how to build the eclipse microprofile-lra artifacts
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-3024
>                 URL: https://issues.jboss.org/browse/JBTM-3024
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> The lra subsystem depends on the microprofile-lra artifacts which are in a separate repo. build.sh and build.bat need build these dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:44:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3024) Make sure top level
 README says how to build the eclipse microprofile-lra artifacts
In-Reply-To: <JIRA.12751204.1526900795000@Atlassian.JIRA>
References: <JIRA.12751204.1526900795000@Atlassian.JIRA>
	<JIRA.12751204.1526900795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751204.1526900795000.40738.1526967840423@Atlassian.JIRA>


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

Amos Feng closed JBTM-3024.
---------------------------


> Make sure top level README says how to build the eclipse microprofile-lra artifacts
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-3024
>                 URL: https://issues.jboss.org/browse/JBTM-3024
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.8.2.Final
>
>
> The lra subsystem depends on the microprofile-lra artifacts which are in a separate repo. build.sh and build.bat need build these dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:44:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3022) The build should build
 the (deprecated) lra-annotations module
In-Reply-To: <JIRA.12750455.1526460728000@Atlassian.JIRA>
References: <JIRA.12750455.1526460728000@Atlassian.JIRA>
	<JIRA.12750455.1526460728000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12750455.1526460728000.40741.1526967840485@Atlassian.JIRA>


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

Amos Feng closed JBTM-3022.
---------------------------


> The build should build the (deprecated) lra-annotations module
> --------------------------------------------------------------
>
>                 Key: JBTM-3022
>                 URL: https://issues.jboss.org/browse/JBTM-3022
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.8.2.Final
>
>
> the lra parent pom should include a build of the lra-annotations module:
> <module>lra-annotations</module>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:44:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3016) NoSuchFieldException
 throws when setting the pool properties
In-Reply-To: <JIRA.12747153.1524729045000@Atlassian.JIRA>
References: <JIRA.12747153.1524729045000@Atlassian.JIRA>
	<JIRA.12747153.1524729045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747153.1524729045000.40744.1526967840554@Atlassian.JIRA>


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

Amos Feng closed JBTM-3016.
---------------------------


> NoSuchFieldException throws when setting the pool properties
> ------------------------------------------------------------
>
>                 Key: JBTM-3016
>                 URL: https://issues.jboss.org/browse/JBTM-3016
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.8.2.Final
>
>
> I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:44:00 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3015) Tomcat JTA: Race
 condition in tx recovery makes PeriodicRecovery run forever
In-Reply-To: <JIRA.12746790.1524575227000@Atlassian.JIRA>
References: <JIRA.12746790.1524575227000@Atlassian.JIRA>
	<JIRA.12746790.1524575227000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12746790.1524575227000.40749.1526967840674@Atlassian.JIRA>


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

Amos Feng closed JBTM-3015.
---------------------------


> Tomcat JTA: Race condition in tx recovery makes PeriodicRecovery run forever
> ----------------------------------------------------------------------------
>
>                 Key: JBTM-3015
>                 URL: https://issues.jboss.org/browse/JBTM-3015
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>         Environment: Oracle JDK 8, Linux, 8 CPU system
>            Reporter: Michal Karm Babacek
>            Assignee: Amos Feng
>            Priority: Critical
>             Fix For: 5.8.2.Final
>
>         Attachments: good_threaddumps.zip, postgresql_trace_log.zip, test.war, thread_dumps_in_sequence_over_time.zip, tomcat_logs.zip
>
>
> There is a simple [recovery test in the test suite|https://github.com/jbosstm/narayana/blob/master/tomcat/tomcat-jta/src/test/java/org/jboss/narayana/tomcat/jta/integration/BaseITCase.java#L141] that runs 3 times in a row. If you change that number to 4, there is a good change you will get the TS stuck forever. When I attached debugger and used breakpoints on the iteration, e.g. {{i==3}} or {{i==10}}, the error was not shown, the TS run and completed, so it is clearly a time related race condition.
> *EDIT:* When I use 30 iterations and a conditional breakpoint on {{i -> test(EXECUTOR_URL + RECOVERY_TEST)}} set to {{i == 28}} the execution loops forever even with debugger attached.
> In this JIRA's example, to reproduce, simply:
> {noformat}
> -        IntStream.range(0, 3).forEach(i -> test(EXECUTOR_URL + RECOVERY_TEST));
> +        IntStream.range(0, 10).forEach(i -> test(EXECUTOR_URL + RECOVERY_TEST));
> {noformat}
> When the Tomcat gets into this unfortunate state and TS hangs and Tomcat runs forever, this is what keeps showing in the database trace (and nothing else):
> {noformat}
> ...
> 2018-04-24 12:37:50.406 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:37:54.410 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:37:58.415 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:02.419 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:06.421 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:10.423 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:14.426 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> 2018-04-24 12:38:18.429 UTC transaction_id: 0 LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts where database = current_database()
> ...
> {noformat}
> I found this Atomikos related reference [online|https://fogbugz.atomikos.com/default13dd.html?community.6.3576.0].
> Tomcat log keeps showing again and again:
> {noformat}
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread Status <== SCANNING
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread scanning
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal Periodic recovery first pass at Tue, 24 Apr 2018 14:41:02
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkFirstPass AtomicActionRecoveryModule first pass
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactions processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:02.537 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change IDLE->FIRST_PASS
> 24-Apr-2018 14:41:02.538 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass Local XARecoveryModule - first pass
> 24-Apr-2018 14:41:02.538 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass xarecovery of org.postgresql.xa.PGXAConnection at 2c8cb5bd
> 24-Apr-2018 14:41:02.538 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass Found 0 xids in doubt
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass xarecovery of org.jboss.narayana.tomcat.jta.integration.app.TestXAResource at 4094781e
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass Found 0 xids in doubt
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change FIRST_PASS->BETWEEN_PASSES
> 24-Apr-2018 14:41:02.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal Periodic recovery second pass at Tue, 24 Apr 2018 14:41:04
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass AtomicActionRecoveryModule second pass
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass Local XARecoveryModule - second pass
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass Local XARecoveryModule.transactionInitiatedRecovery completed
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass xarecovery second pass of org.postgresql.xa.PGXAConnection at 2c8cb5bd
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass Have 0 Xids to recover on this pass.
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass xarecovery second pass of org.jboss.narayana.tomcat.jta.integration.app.TestXAResource at 4094781e
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass Have 0 Xids to recover on this pass.
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass Local XARecoveryModule.resourceInitiatedRecovery completed
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState XARecoveryModule state change SECOND_PASS->IDLE
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal  
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread Status <== INACTIVE
> 24-Apr-2018 14:41:04.539 DEBUG [Periodic Recovery] com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run PeriodicRecovery: background thread backing off
> {noformat} 
> h3. Logs and thread dumps
> * [^postgresql_trace_log.zip] -- PostgreSQL trace, note the originally expected course of recoveries and then the repeated stuck on the aforementioned message.
> * [^test.war] -- test app used; the TS builds it for you though and stores it in {{tomcat/tomcat-deployment/_DEFAULT__Basic-app_test.war}}
> * [^thread_dumps_in_sequence_over_time.zip] -- thread dumps taken over time with minutes in between snaps.
> * [^tomcat_logs.zip] -- Tomcat logs
> * [^good_threaddumps.zip] --  a dozen of snapshots couple of seconds from each other as an example of a good TS run that terminates as expected, i.e. with {{IntStream.range(0, 3).forEach(i -> test(EXECUTOR_URL + RECOVERY_TEST));}}.
> * This is what good, i.e. 3 iterations long DB trace looks like: [good db trace|https://paste.fedoraproject.org/paste/drANRRl4DlckwLhSIwCOdA/raw].
> * This is what good, i.e. 3 iterations long Tomcat catalina log looks like:  [catalina log|https://paste.fedoraproject.org/paste/CkaDCZCtoVhDtyTglEOFqg/raw]
> Might interest also [~ochaloup].   WDYT guys? What should I try out?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3014) Support all the pooling
 parameters of the DBCP2 in the TransactionalDataSourceFactory
In-Reply-To: <JIRA.12745606.1524026506000@Atlassian.JIRA>
References: <JIRA.12745606.1524026506000@Atlassian.JIRA>
	<JIRA.12745606.1524026506000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12745606.1524026506000.40753.1526967901212@Atlassian.JIRA>


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

Amos Feng closed JBTM-3014.
---------------------------


> Support all the pooling parameters of the DBCP2 in the TransactionalDataSourceFactory
> -------------------------------------------------------------------------------------
>
>                 Key: JBTM-3014
>                 URL: https://issues.jboss.org/browse/JBTM-3014
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.8.2.Final
>
>
> Currently we just support the minIdle, maxIdle, maxTotal and it needs to support all the configuration parameters [1].
> [1] https://commons.apache.org/proper/commons-dbcp/configuration.html



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3013) Update Tomcat integration
 test to be able to use Postgres database
In-Reply-To: <JIRA.12745020.1523634851000@Atlassian.JIRA>
References: <JIRA.12745020.1523634851000@Atlassian.JIRA>
	<JIRA.12745020.1523634851000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12745020.1523634851000.40757.1526967901328@Atlassian.JIRA>


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

Amos Feng closed JBTM-3013.
---------------------------


> Update Tomcat integration test to be able to use Postgres database
> ------------------------------------------------------------------
>
>                 Key: JBTM-3013
>                 URL: https://issues.jboss.org/browse/JBTM-3013
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Tomcat
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.8.2.Final
>
>
> Currently it uses H2 but it would be useful to demonstrate this working on Postgres too



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3012) Cache recovery connection
 in Tomcat integration
In-Reply-To: <JIRA.12744974.1523625726000@Atlassian.JIRA>
References: <JIRA.12744974.1523625726000@Atlassian.JIRA>
	<JIRA.12744974.1523625726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12744974.1523625726000.40760.1526967901410@Atlassian.JIRA>


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

Amos Feng closed JBTM-3012.
---------------------------


> Cache recovery connection in Tomcat integration
> -----------------------------------------------
>
>                 Key: JBTM-3012
>                 URL: https://issues.jboss.org/browse/JBTM-3012
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Tomcat
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.8.2.Final
>
>
> The current TransactionalDataSourceFactory allocates a new XAConnection per recovery manager cycle. It would be better to close it or cache it so we don't get the possibility of a leak with perhaps some databases



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3008) Upgrade to Tomcat 9.0
In-Reply-To: <JIRA.12744388.1523408920000@Atlassian.JIRA>
References: <JIRA.12744388.1523408920000@Atlassian.JIRA>
	<JIRA.12744388.1523408920000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12744388.1523408920000.40763.1526967901489@Atlassian.JIRA>


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

Amos Feng closed JBTM-3008.
---------------------------


> Upgrade to Tomcat 9.0
> ---------------------
>
>                 Key: JBTM-3008
>                 URL: https://issues.jboss.org/browse/JBTM-3008
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>            Reporter: Amos Feng
>            Assignee: Tom Jenkinson
>             Fix For: 5.8.2.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
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.40767.1526967901584@Atlassian.JIRA>


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

Amos Feng updated JBTM-3020:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> 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
>             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.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3019) Testsuite: Docker
 controller leaves stray volumes and fills up disk space unnecessairly over
 time
In-Reply-To: <JIRA.12748357.1525329873000@Atlassian.JIRA>
References: <JIRA.12748357.1525329873000@Atlassian.JIRA>
	<JIRA.12748357.1525329873000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12748357.1525329873000.40770.1526967901643@Atlassian.JIRA>


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

Amos Feng updated JBTM-3019:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-3019
>                 URL: https://issues.jboss.org/browse/JBTM-3019
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Testing
>    Affects Versions: 5.8.1.Final
>         Environment: Docker enabled Jenkins slaves
>            Reporter: Michal Karm Babacek
>            Assignee: Michal Karm Babacek
>            Priority: Minor
>             Fix For: 5.next
>
>
> h3. Problem
> The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images:
> {code}
> [root at karm-centos7-x86-64 ~]# docker images
> REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
> docker.io/postgres   9.4                 26bd9b04b948        6 days ago          232 MB
> docker.io/postgres   10                  0965cdc98045        6 days ago          234 MB
> docker.io/postgres   <none>              ed5db6e669ff        7 weeks ago         263 MB
> docker.io/postgres   <none>              30121e967865        7 weeks ago         289 MB
> [root at karm-centos7-x86-64 ~]# docker ps -a
> CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
> [root at karm-centos7-x86-64 ~]# 
> {code}
> Although it leaves stray container volumes for some reason:
> {code}
> [root at karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes
> 15G	/var/lib/docker-latest/volumes
> [root at karm-centos7-x86-64 ~]# docker volume ls -qf dangling=true | wc -l
> 409
> {code}
> It unnecessarily clogs the slaves' disk space. The 15G of garbage has been created over dozens and dozens of builds with at least two containers each, but it shouldn't be happening anyway.
> h3. Call to action
> Review whether [removeContainerCmd|https://github.com/jbosstm/narayana/blob/master/tools/src/main/java/io/narayana/db/PostgreContainerAllocator.java#L264] is supposed to be enough to not only remove the container but to also remove its volume.
> h3. Workaround
> {code}
> docker volume prune
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3017) Provide a check to see if
 the last recovery scan "cleaned" the store.
In-Reply-To: <JIRA.12747622.1524853346000@Atlassian.JIRA>
References: <JIRA.12747622.1524853346000@Atlassian.JIRA>
	<JIRA.12747622.1524853346000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12747622.1524853346000.40775.1526967901800@Atlassian.JIRA>


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

Amos Feng updated JBTM-3017:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


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



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:01 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3010) Move the tomcat-jta
 module out of the narayana repo
In-Reply-To: <JIRA.12744769.1523542662000@Atlassian.JIRA>
References: <JIRA.12744769.1523542662000@Atlassian.JIRA>
	<JIRA.12744769.1523542662000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12744769.1523542662000.40779.1526967901916@Atlassian.JIRA>


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

Amos Feng updated JBTM-3010:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Move the tomcat-jta module out of the narayana repo
> ---------------------------------------------------
>
>                 Key: JBTM-3010
>                 URL: https://issues.jboss.org/browse/JBTM-3010
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Minor
>             Fix For: 5.next
>
>
> We tend to prefer the integration code for specific application servers be kept outside of the main Narayana transaction manager repository as it tends to iterate under different release cycle also.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3009) Add the Transactional
 datasource factory in the tomcat-jta
In-Reply-To: <JIRA.12744766.1523542496000@Atlassian.JIRA>
References: <JIRA.12744766.1523542496000@Atlassian.JIRA>
	<JIRA.12744766.1523542496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12744766.1523542496000.40783.1526967902063@Atlassian.JIRA>


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

Amos Feng updated JBTM-3009:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Add the Transactional datasource factory in the tomcat-jta
> ----------------------------------------------------------
>
>                 Key: JBTM-3009
>                 URL: https://issues.jboss.org/browse/JBTM-3009
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> This factory is used to create the datasource with the common-dbcp2 and support XA and pooling, 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
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.40786.1526967902150@Atlassian.JIRA>


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

Amos Feng updated JBTM-2968:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> 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
>             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.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2967) Some quickstarts are not
	tested in CI
In-Reply-To: <JIRA.12721857.1511285782000@Atlassian.JIRA>
References: <JIRA.12721857.1511285782000@Atlassian.JIRA>
	<JIRA.12721857.1511285782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721857.1511285782000.40789.1526967902226@Atlassian.JIRA>


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

Amos Feng updated JBTM-2967:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Some quickstarts are not tested in CI
> -------------------------------------
>
>                 Key: JBTM-2967
>                 URL: https://issues.jboss.org/browse/JBTM-2967
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage.
> This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart.
> The following poms do execute a run script
> transactionaldriver-jpa-and-tomcat/pom.xml
> rts/at/simple/pom.xml
> rts/lra/lra-test/pom.xml
> ArjunaJTS/interop/glassfish/pom.xml
> transactionaldriver-and-tomcat/pom.xml
> spring/camel-with-narayana-spring-boot/pom.xml
> The following quickstarts contain run scripts:
> transactionaldriver-jpa-and-tomcat/run.sh
> ArjunaCore/txoj/run.sh
> jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh
> ArjunaJTA/object_store/run.sh
> ArjunaJTA/maven/run.sh
> ArjunaJTA/recovery/run.sh
> ArjunaJTA/javax_transaction/run.sh
> rts/at/undertow/run.sh
> rts/at/recovery/recovery2/run.sh
> rts/at/recovery/recovery1/run.sh
> rts/at/simple/run.sh
> rts/at/service/service2b/run.sh
> rts/at/service/service2/run.sh
> rts/at/service/service1b/run.sh
> rts/at/service/service1/run.sh
> rts/at/demo/run.sh
> rts/lra/run.sh
> ArjunaJTS/standalone/run.sh
> ArjunaJTS/interop/glassfish/run.sh
> ArjunaJTS/recovery/run.sh



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2966) narayana-quickstarts-jts
 quickstart does not run standalone
In-Reply-To: <JIRA.12721855.1511285155000@Atlassian.JIRA>
References: <JIRA.12721855.1511285155000@Atlassian.JIRA>
	<JIRA.12721855.1511285155000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721855.1511285155000.40793.1526967902356@Atlassian.JIRA>


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

Amos Feng updated JBTM-2966:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> narayana-quickstarts-jts quickstart does not run standalone
> -----------------------------------------------------------
>
>                 Key: JBTM-2966
>                 URL: https://issues.jboss.org/browse/JBTM-2966
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> The recovery quickstart does not run due to missing maven jboss-transaction-spi dependency.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2965) Unused source directory
 in the quickstart repository
In-Reply-To: <JIRA.12721827.1511280306000@Atlassian.JIRA>
References: <JIRA.12721827.1511280306000@Atlassian.JIRA>
	<JIRA.12721827.1511280306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721827.1511280306000.40797.1526967902503@Atlassian.JIRA>


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

Amos Feng updated JBTM-2965:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Unused source directory in the quickstart repository
> ----------------------------------------------------
>
>                 Key: JBTM-2965
>                 URL: https://issues.jboss.org/browse/JBTM-2965
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Demonstrator
>    Affects Versions: 5.7.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> There is an artifact in our quickstart repo that does not look like a quickstart and no other pom in the quickstart and performance repositories references the artifact:
> https://github.com/jbosstm/quickstart/tree/master/ArjunaJTS/jta
> It has never changed since the initial commit:
> {quote}
> commit caabc37803bac12e47f4986baca21f9052e14abc
> Author: Tom Jenkinson <tom.jenkinson at redhat.com>
> Date:   Tue Oct 2 11:05:51 2012 +0100
>     Initial version of a performance comparitor for jts and jta
> {quote}
> This artefact needs deleting.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true
 dependency of standalone narayana-jta pom.xml
In-Reply-To: <JIRA.12699316.1498490427000@Atlassian.JIRA>
References: <JIRA.12699316.1498490427000@Atlassian.JIRA>
	<JIRA.12699316.1498490427000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699316.1498490427000.40800.1526967902577@Atlassian.JIRA>


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

Amos Feng updated JBTM-2913:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Make the SPI a true dependency of standalone narayana-jta pom.xml
> -----------------------------------------------------------------
>
>                 Key: JBTM-2913
>                 URL: https://issues.jboss.org/browse/JBTM-2913
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next
>
>
> This means that users can simply import the narayana-jta dependency rather than both it and the SPI.
> It is useful when being consumed by jbpm for example.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional
 driver to JMS 2.0
In-Reply-To: <JIRA.12699282.1498485630000@Atlassian.JIRA>
References: <JIRA.12699282.1498485630000@Atlassian.JIRA>
	<JIRA.12699282.1498485630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699282.1498485630000.40803.1526967902696@Atlassian.JIRA>


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

Amos Feng updated JBTM-2912:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Upgrade JMS transactional driver to JMS 2.0
> -------------------------------------------
>
>                 Key: JBTM-2912
>                 URL: https://issues.jboss.org/browse/JBTM-2912
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: JMS
>            Reporter: Tom Jenkinson
>             Fix For: 5.next
>
>
> The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList
 protected access to _work object
In-Reply-To: <JIRA.12683118.1489748298000@Atlassian.JIRA>
References: <JIRA.12683118.1489748298000@Atlassian.JIRA>
	<JIRA.12683118.1489748298000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12683118.1489748298000.40805.1526967902753@Atlassian.JIRA>


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

Amos Feng updated JBTM-2867:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Investigate un-_workList protected access to _work object
> ---------------------------------------------------------
>
>                 Key: JBTM-2867
>                 URL: https://issues.jboss.org/browse/JBTM-2867
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next
>
>
> During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues.
> For example, this looks wrong:
> https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703
> If
> https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a
 version of WildFly that works with JDK9 (when available)
In-Reply-To: <JIRA.12678019.1487665156000@Atlassian.JIRA>
References: <JIRA.12678019.1487665156000@Atlassian.JIRA>
	<JIRA.12678019.1487665156000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678019.1487665156000.40808.1526967902832@Atlassian.JIRA>


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

Amos Feng updated JBTM-2851:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> Upgrade BlackTie to a version of WildFly that works with JDK9 (when available)
> ------------------------------------------------------------------------------
>
>                 Key: JBTM-2851
>                 URL: https://issues.jboss.org/browse/JBTM-2851
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2].
> So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release.
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html
> [2] https://github.com/jboss/openjdk-orb/pull/4



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 01:45:02 2018
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 22 May 2018 01:45:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841)
 HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send()
In-Reply-To: <JIRA.12671589.1484662875000@Atlassian.JIRA>
References: <JIRA.12671589.1484662875000@Atlassian.JIRA>
	<JIRA.12671589.1484662875000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671589.1484662875000.40811.1526967902905@Atlassian.JIRA>


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

Amos Feng updated JBTM-2841:
----------------------------
    Fix Version/s: 5.next
                       (was: 5.8.2.Final)


> HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send()
> -------------------------------------------------------------------------
>
>                 Key: JBTM-2841
>                 URL: https://issues.jboss.org/browse/JBTM-2841
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: BlackTie
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> tpreturn() seems to non-block send without checking tranfer length.
> It needs a wrapper of looping apr_socket_send() until all of the data write to the socket.
> similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 09:29:01 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Tue, 22 May 2018 09:29:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3025) Xid created for JTS
 imported transaction set up wrong node name
In-Reply-To: <JIRA.12751465.1526995725000@Atlassian.JIRA>
References: <JIRA.12751465.1526995725000@Atlassian.JIRA>
	<JIRA.12751465.1526995725964@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751465.1526995725000.45272.1526995741606@Atlassian.JIRA>

Ondra Chaloupka created JBTM-3025:
-------------------------------------

             Summary: Xid created for JTS imported transaction set up wrong node name
                 Key: JBTM-3025
                 URL: https://issues.jboss.org/browse/JBTM-3025
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: JTS
    Affects Versions: 5.8.2.Final
            Reporter: Ondra Chaloupka
            Assignee: Ondra Chaloupka
            Priority: Critical


For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node.

I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 09:40:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Tue, 22 May 2018 09:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3025) Xid created for JTS
 imported transaction set up wrong node name
In-Reply-To: <JIRA.12751465.1526995726000@Atlassian.JIRA>
References: <JIRA.12751465.1526995726000@Atlassian.JIRA>
	<JIRA.12751465.1526995726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751465.1526995726000.45479.1526996400551@Atlassian.JIRA>


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

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


> Xid created for JTS imported transaction set up wrong node name
> ---------------------------------------------------------------
>
>                 Key: JBTM-3025
>                 URL: https://issues.jboss.org/browse/JBTM-3025
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTS
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Critical
>
> For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node.
> I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue May 22 16:42:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 22 May 2018 16:42:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2979) Timeout leaves LRA active
 and able to complete
In-Reply-To: <JIRA.12725965.1513944410000@Atlassian.JIRA>
References: <JIRA.12725965.1513944410000@Atlassian.JIRA>
	<JIRA.12725965.1513944410000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725965.1513944410000.48425.1527021720091@Atlassian.JIRA>


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

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


> Timeout leaves LRA active and able to complete
> ----------------------------------------------
>
>                 Key: JBTM-2979
>                 URL: https://issues.jboss.org/browse/JBTM-2979
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Nicola Ferraro
>            Assignee: Michael Musgrove
>
> If a participant declares a timeout, the coordinator calls its "/compensate" endpoint when the timeout expires. But the LRA remains active and it may be possibly closed, leading to a second call to "/complete" on the participant, even if he has already compensated.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 23 04:52:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 23 May 2018 04:52:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2977) Participants should not
 be told to compensate after completion
In-Reply-To: <JIRA.12725953.1513933458000@Atlassian.JIRA>
References: <JIRA.12725953.1513933458000@Atlassian.JIRA>
	<JIRA.12725953.1513933458000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725953.1513933458000.50062.1527065520356@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2977:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Participants should not be told to compensate after completion
> --------------------------------------------------------------
>
>                 Key: JBTM-2977
>                 URL: https://issues.jboss.org/browse/JBTM-2977
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Nicola Ferraro
>            Assignee: Michael Musgrove
>
> When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond.
> While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed.
> The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case).
> A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time.
> I attach few simple steps to reproduce it with shell commands.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 23 09:25:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 09:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests are issues to
 be build on machines/jdk preferring IPv6
In-Reply-To: <JIRA.12751638.1527081846000@Atlassian.JIRA>
References: <JIRA.12751638.1527081846000@Atlassian.JIRA>
	<JIRA.12751638.1527081846824@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751638.1527081846000.53347.1527081900430@Atlassian.JIRA>

Ondra Chaloupka created JBTM-3026:
-------------------------------------

             Summary: LRA tests are issues to be build on machines/jdk preferring IPv6
                 Key: JBTM-3026
                 URL: https://issues.jboss.org/browse/JBTM-3026
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.8.2.Final
            Reporter: Ondra Chaloupka
            Assignee: Ondra Chaloupka


There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound.

see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}}

{code}
[0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final
[0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
[0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
??at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketException: Protocol family unavailable
??at sun.nio.ch.Net.bind0(Native Method)
??at sun.nio.ch.Net.bind(Net.java:433)
??at sun.nio.ch.Net.bind(Net.java:425)
??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
??... 5 more

[0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
????("subsystem" => "undertow"),
????("server" => "default-server"),
????("http-listener" => "default")
]) - failure description: {
????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
????Caused by: java.net.SocketException: Protocol family unavailable"},
????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"],
????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
[0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.

[0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
[0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
[0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
[0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
[0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
[0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
[0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more
[0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested
[0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal
[0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping
[0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed May 23 09:25:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 09:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests cause issues
 when being built on machines/jdk preferring IPv6
In-Reply-To: <JIRA.12751638.1527081847000@Atlassian.JIRA>
References: <JIRA.12751638.1527081847000@Atlassian.JIRA>
	<JIRA.12751638.1527081847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751638.1527081847000.53353.1527081900596@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3026:
----------------------------------
    Summary: LRA tests cause issues when being built on machines/jdk preferring IPv6  (was: LRA tests are issues to be build on machines/jdk preferring IPv6)


> LRA tests cause issues when being built on machines/jdk preferring IPv6
> -----------------------------------------------------------------------
>
>                 Key: JBTM-3026
>                 URL: https://issues.jboss.org/browse/JBTM-3026
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound.
> see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}}
> {code}
> [0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final
> [0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ??at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.SocketException: Protocol family unavailable
> ??at sun.nio.ch.Net.bind0(Native Method)
> ??at sun.nio.ch.Net.bind(Net.java:433)
> ??at sun.nio.ch.Net.bind(Net.java:425)
> ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> ??... 5 more
> [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ????("subsystem" => "undertow"),
> ????("server" => "default-server"),
> ????("http-listener" => "default")
> ]) - failure description: {
> ????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ????Caused by: java.net.SocketException: Protocol family unavailable"},
> ????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"],
> ????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> [0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more
> [0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested
> [0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal
> [0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping
> [0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed May 23 11:05:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 11:05:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3027) Failing LRA quickstarts
 as Narayana still reports dependency at lra annotations
In-Reply-To: <JIRA.12751682.1527087877000@Atlassian.JIRA>
References: <JIRA.12751682.1527087877000@Atlassian.JIRA>
	<JIRA.12751682.1527087877690@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751682.1527087877000.54725.1527087900801@Atlassian.JIRA>

Ondra Chaloupka created JBTM-3027:
-------------------------------------

             Summary: Failing LRA quickstarts as Narayana still reports dependency at lra annotations
                 Key: JBTM-3027
                 URL: https://issues.jboss.org/browse/JBTM-3027
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.8.2.Final
            Reporter: Ondra Chaloupka
            Assignee: Ondra Chaloupka


LRA quickstarts are failing ({{/home/ochaloup/Transactions/quickstart-jbosstm/rts/lra}}) because the fraction which is created from the {{lra-filters}} injects not only eclipse lra annotations but the narayana:lra-annotations dependency too.

There is fail on the injections with errors like

{code}
2018-05-23 16:56:41,684 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."lra-test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-test.war".WeldStartService: Failed to start service
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAClient with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private io.narayana.rts.lra.demo.flight.FlightService.lraClient
  at io.narayana.rts.lra.demo.flight.FlightService.lraClient(FlightService.java:0)

        at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
        at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 23 11:13:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 11:13:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests cause issues
 when being built on machines/jdk preferring IPv6
In-Reply-To: <JIRA.12751638.1527081847000@Atlassian.JIRA>
References: <JIRA.12751638.1527081847000@Atlassian.JIRA>
	<JIRA.12751638.1527081847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751638.1527081847000.54778.1527088380527@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3026:
----------------------------------
    Git Pull Request: https://github.com/jbosstm/narayana/pull/1325


> LRA tests cause issues when being built on machines/jdk preferring IPv6
> -----------------------------------------------------------------------
>
>                 Key: JBTM-3026
>                 URL: https://issues.jboss.org/browse/JBTM-3026
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound.
> see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}}
> {code}
> [0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final
> [0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ??at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.SocketException: Protocol family unavailable
> ??at sun.nio.ch.Net.bind0(Native Method)
> ??at sun.nio.ch.Net.bind(Net.java:433)
> ??at sun.nio.ch.Net.bind(Net.java:425)
> ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> ??... 5 more
> [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ????("subsystem" => "undertow"),
> ????("server" => "default-server"),
> ????("http-listener" => "default")
> ]) - failure description: {
> ????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ????Caused by: java.net.SocketException: Protocol family unavailable"},
> ????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"],
> ????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> [0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more
> [0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested
> [0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal
> [0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping
> [0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed May 23 11:13:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 11:13:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests cause issues
 when being built on machines/jdk preferring IPv6
In-Reply-To: <JIRA.12751638.1527081847000@Atlassian.JIRA>
References: <JIRA.12751638.1527081847000@Atlassian.JIRA>
	<JIRA.12751638.1527081847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751638.1527081847000.54780.1527088380574@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3026:
----------------------------------
    Status: Pull Request Sent  (was: Open)


> LRA tests cause issues when being built on machines/jdk preferring IPv6
> -----------------------------------------------------------------------
>
>                 Key: JBTM-3026
>                 URL: https://issues.jboss.org/browse/JBTM-3026
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound.
> see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}}
> {code}
> [0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final
> [0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ??at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.SocketException: Protocol family unavailable
> ??at sun.nio.ch.Net.bind0(Native Method)
> ??at sun.nio.ch.Net.bind(Net.java:433)
> ??at sun.nio.ch.Net.bind(Net.java:425)
> ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> ??... 5 more
> [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ????("subsystem" => "undertow"),
> ????("server" => "default-server"),
> ????("http-listener" => "default")
> ]) - failure description: {
> ????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ????Caused by: java.net.SocketException: Protocol family unavailable"},
> ????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"],
> ????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> [0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more
> [0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested
> [0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal
> [0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping
> [0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed May 23 11:13:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 11:13:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests cause issues
 when being built on machines/jdk preferring IPv6
In-Reply-To: <JIRA.12751638.1527081847000@Atlassian.JIRA>
References: <JIRA.12751638.1527081847000@Atlassian.JIRA>
	<JIRA.12751638.1527081847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751638.1527081847000.54782.1527088380629@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3026:
----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> LRA tests cause issues when being built on machines/jdk preferring IPv6
> -----------------------------------------------------------------------
>
>                 Key: JBTM-3026
>                 URL: https://issues.jboss.org/browse/JBTM-3026
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound.
> see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}}
> {code}
> [0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final
> [0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ??at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.SocketException: Protocol family unavailable
> ??at sun.nio.ch.Net.bind0(Native Method)
> ??at sun.nio.ch.Net.bind(Net.java:433)
> ??at sun.nio.ch.Net.bind(Net.java:425)
> ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> ??... 5 more
> [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ????("subsystem" => "undertow"),
> ????("server" => "default-server"),
> ????("http-listener" => "default")
> ]) - failure description: {
> ????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> ????Caused by: java.net.SocketException: Protocol family unavailable"},
> ????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"],
> ????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> [0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more
> [0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested
> [0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal
> [0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping
> [0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed May 23 11:14:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 23 May 2018 11:14:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3025) Xid created for JTS
 imported transaction set up wrong node name
In-Reply-To: <JIRA.12751465.1526995726000@Atlassian.JIRA>
References: <JIRA.12751465.1526995726000@Atlassian.JIRA>
	<JIRA.12751465.1526995726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751465.1526995726000.54788.1527088440255@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3025:
----------------------------------
    Git Pull Request: https://github.com/jbosstm/narayana/pull/1323


> Xid created for JTS imported transaction set up wrong node name
> ---------------------------------------------------------------
>
>                 Key: JBTM-3025
>                 URL: https://issues.jboss.org/browse/JBTM-3025
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTS
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Critical
>
> For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node.
> I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed May 23 14:26:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 23 May 2018 14:26:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2979) Timeout leaves LRA active
 and able to complete
In-Reply-To: <JIRA.12725965.1513944410000@Atlassian.JIRA>
References: <JIRA.12725965.1513944410000@Atlassian.JIRA>
	<JIRA.12725965.1513944410000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725965.1513944410000.55721.1527099960103@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2979:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Timeout leaves LRA active and able to complete
> ----------------------------------------------
>
>                 Key: JBTM-2979
>                 URL: https://issues.jboss.org/browse/JBTM-2979
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Nicola Ferraro
>            Assignee: Michael Musgrove
>
> If a participant declares a timeout, the coordinator calls its "/compensate" endpoint when the timeout expires. But the LRA remains active and it may be possibly closed, leading to a second call to "/complete" on the participant, even if he has already compensated.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 24 06:49:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 24 May 2018 06:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2978) Compensation should not
 be considered done in case of network error
In-Reply-To: <JIRA.12725963.1513939207000@Atlassian.JIRA>
References: <JIRA.12725963.1513939207000@Atlassian.JIRA>
	<JIRA.12725963.1513939207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725963.1513939207000.59386.1527158940092@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2978:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Compensation should not be considered done in case of network error
> -------------------------------------------------------------------
>
>                 Key: JBTM-2978
>                 URL: https://issues.jboss.org/browse/JBTM-2978
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.7.1.Final
>            Reporter: Nicola Ferraro
>            Assignee: Michael Musgrove
>
> In case of network error on the call to "/compensate" made by the coordinator to the participant, the LRA is considered compensated, hence the compensate action is not retried again. This is not the expected behavior.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May 25 03:42:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Fri, 25 May 2018 03:42:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3025) Xid created for JTS
 imported transaction set up wrong node name
In-Reply-To: <JIRA.12751465.1526995726000@Atlassian.JIRA>
References: <JIRA.12751465.1526995726000@Atlassian.JIRA>
	<JIRA.12751465.1526995726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751465.1526995726000.65616.1527234120254@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3025:
----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Xid created for JTS imported transaction set up wrong node name
> ---------------------------------------------------------------
>
>                 Key: JBTM-3025
>                 URL: https://issues.jboss.org/browse/JBTM-3025
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTS
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Critical
>
> For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node.
> I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May 25 04:36:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 25 May 2018 04:36:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3028) LRA tests can fail if the
 network is running slowly
In-Reply-To: <JIRA.12751988.1527237307000@Atlassian.JIRA>
References: <JIRA.12751988.1527237307000@Atlassian.JIRA>
	<JIRA.12751988.1527237307667@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751988.1527237307000.65998.1527237360516@Atlassian.JIRA>

Michael Musgrove created JBTM-3028:
--------------------------------------

             Summary: LRA tests can fail if the network is running slowly
                 Key: JBTM-3028
                 URL: https://issues.jboss.org/browse/JBTM-3028
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.8.2.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


SpecIT#acceptTest failed on CI (http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/PROFILE=MAIN,jdk=jdk8.latest,label=linux/187/) and on one of the PRs.

[~ochaloup] did some investigation:
{quote}
I did some experiments with the lra testing and normally tests pass on my laptop. But as you mentioned it's probably timing issue as when I slow down the network (I used tc as described at [1]) then the tests started to fail[2] (I'm on master branch).

Do you think you can check it on your laptop if you can see the same issue? Or how to manage that?

Thanks
o.

[1] https://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-tc/
[2]
Tests run: 23, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 489.336 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT
timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT)  Time elapsed: 14.474 sec  <<< FAILURE!
java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0>
        at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:535)

acceptTest(io.narayana.lra.participant.SpecIT)  Time elapsed: 30.335 sec  <<< FAILURE!
java.lang.AssertionError: expected:<0> but was:<2>
        at io.narayana.lra.participant.SpecIT.joinAndEnd(SpecIT.java:649)
        at io.narayana.lra.participant.SpecIT.acceptTest(SpecIT.java:624)

connectionHangup(io.narayana.lra.participant.SpecIT)  Time elapsed: 35.179 sec  <<< FAILURE!
java.lang.AssertionError: connectionHangup: wrong compensation count after recovery expected:<7> but was:<6>
        at io.narayana.lra.participant.SpecIT.connectionHangup(SpecIT.java:266)
{quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri May 25 05:00:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Fri, 25 May 2018 05:00:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3028) LRA tests can fail if the
 network is running slowly
In-Reply-To: <JIRA.12751988.1527237308000@Atlassian.JIRA>
References: <JIRA.12751988.1527237308000@Atlassian.JIRA>
	<JIRA.12751988.1527237308000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751988.1527237308000.66344.1527238800576@Atlassian.JIRA>


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

Ondra Chaloupka commented on JBTM-3028:
---------------------------------------

I'm able to see the failing test when I run this set of commands

{code}
# build narayana
cd rts/lra/lra-test
sudo tc qdisc add dev lo root netem delay 500ms
tc qdisc
# (observe the rule on delaying network is set up)
# [root at ochaloup ochaloup]# tc qdisc
# qdisc netem 8001: dev lo root refcnt 2 limit 1000 delay 500.0ms
mvn verify -Dit.test=SpecIT#acceptTest
# (observe failure)
# Failed tests:
#    SpecIT.acceptTest:624->joinAndEnd:649 expected:<0> but was:<2>
sudo tc qdisc del dev lo root netem
{code}

> LRA tests can fail if the network is running slowly
> ---------------------------------------------------
>
>                 Key: JBTM-3028
>                 URL: https://issues.jboss.org/browse/JBTM-3028
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> SpecIT#acceptTest failed on CI (http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/PROFILE=MAIN,jdk=jdk8.latest,label=linux/187/) and on one of the PRs.
> [~ochaloup] did some investigation:
> {quote}
> I did some experiments with the lra testing and normally tests pass on my laptop. But as you mentioned it's probably timing issue as when I slow down the network (I used tc as described at [1]) then the tests started to fail[2] (I'm on master branch).
> Do you think you can check it on your laptop if you can see the same issue? Or how to manage that?
> Thanks
> o.
> [1] https://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-tc/
> [2]
> Tests run: 23, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 489.336 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT
> timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT)  Time elapsed: 14.474 sec  <<< FAILURE!
> java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0>
>         at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:535)
> acceptTest(io.narayana.lra.participant.SpecIT)  Time elapsed: 30.335 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<2>
>         at io.narayana.lra.participant.SpecIT.joinAndEnd(SpecIT.java:649)
>         at io.narayana.lra.participant.SpecIT.acceptTest(SpecIT.java:624)
> connectionHangup(io.narayana.lra.participant.SpecIT)  Time elapsed: 35.179 sec  <<< FAILURE!
> java.lang.AssertionError: connectionHangup: wrong compensation count after recovery expected:<7> but was:<6>
>         at io.narayana.lra.participant.SpecIT.connectionHangup(SpecIT.java:266)
> {quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 31 08:19:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 31 May 2018 08:19:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3028) LRA tests can fail if the
 network is running slowly
In-Reply-To: <JIRA.12751988.1527237308000@Atlassian.JIRA>
References: <JIRA.12751988.1527237308000@Atlassian.JIRA>
	<JIRA.12751988.1527237308000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751988.1527237308000.102945.1527769140777@Atlassian.JIRA>


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

Michael Musgrove commented on JBTM-3028:
----------------------------------------

The delay can result in the recovery process not being able to complete recovery of participants so the test assertions that recovery succeeded fail.

The fix to the test is to retry the recovery pass a fixed number of times. Note that the delay on every packet is unreasonable and results in recovery never being able to succeed.

> LRA tests can fail if the network is running slowly
> ---------------------------------------------------
>
>                 Key: JBTM-3028
>                 URL: https://issues.jboss.org/browse/JBTM-3028
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> SpecIT#acceptTest failed on CI (http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/PROFILE=MAIN,jdk=jdk8.latest,label=linux/187/) and on one of the PRs.
> [~ochaloup] did some investigation:
> {quote}
> I did some experiments with the lra testing and normally tests pass on my laptop. But as you mentioned it's probably timing issue as when I slow down the network (I used tc as described at [1]) then the tests started to fail[2] (I'm on master branch).
> Do you think you can check it on your laptop if you can see the same issue? Or how to manage that?
> Thanks
> o.
> [1] https://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-tc/
> [2]
> Tests run: 23, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 489.336 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT
> timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT)  Time elapsed: 14.474 sec  <<< FAILURE!
> java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0>
>         at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:535)
> acceptTest(io.narayana.lra.participant.SpecIT)  Time elapsed: 30.335 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<2>
>         at io.narayana.lra.participant.SpecIT.joinAndEnd(SpecIT.java:649)
>         at io.narayana.lra.participant.SpecIT.acceptTest(SpecIT.java:624)
> connectionHangup(io.narayana.lra.participant.SpecIT)  Time elapsed: 35.179 sec  <<< FAILURE!
> java.lang.AssertionError: connectionHangup: wrong compensation count after recovery expected:<7> but was:<6>
>         at io.narayana.lra.participant.SpecIT.connectionHangup(SpecIT.java:266)
> {quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 31 11:05:00 2018
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 31 May 2018 11:05:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3028) LRA tests can fail if the
 network is running slowly
In-Reply-To: <JIRA.12751988.1527237308000@Atlassian.JIRA>
References: <JIRA.12751988.1527237308000@Atlassian.JIRA>
	<JIRA.12751988.1527237308000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751988.1527237308000.104941.1527779100101@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-3028:
-----------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/jbosstm/narayana/pull/1331


> LRA tests can fail if the network is running slowly
> ---------------------------------------------------
>
>                 Key: JBTM-3028
>                 URL: https://issues.jboss.org/browse/JBTM-3028
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> SpecIT#acceptTest failed on CI (http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/PROFILE=MAIN,jdk=jdk8.latest,label=linux/187/) and on one of the PRs.
> [~ochaloup] did some investigation:
> {quote}
> I did some experiments with the lra testing and normally tests pass on my laptop. But as you mentioned it's probably timing issue as when I slow down the network (I used tc as described at [1]) then the tests started to fail[2] (I'm on master branch).
> Do you think you can check it on your laptop if you can see the same issue? Or how to manage that?
> Thanks
> o.
> [1] https://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-tc/
> [2]
> Tests run: 23, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 489.336 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT
> timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT)  Time elapsed: 14.474 sec  <<< FAILURE!
> java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0>
>         at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:535)
> acceptTest(io.narayana.lra.participant.SpecIT)  Time elapsed: 30.335 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<2>
>         at io.narayana.lra.participant.SpecIT.joinAndEnd(SpecIT.java:649)
>         at io.narayana.lra.participant.SpecIT.acceptTest(SpecIT.java:624)
> connectionHangup(io.narayana.lra.participant.SpecIT)  Time elapsed: 35.179 sec  <<< FAILURE!
> java.lang.AssertionError: connectionHangup: wrong compensation count after recovery expected:<7> but was:<6>
>         at io.narayana.lra.participant.SpecIT.connectionHangup(SpecIT.java:266)
> {quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 31 11:25:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Thu, 31 May 2018 11:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3027) Failing LRA quickstarts
 as Narayana still reports dependency at lra annotations
In-Reply-To: <JIRA.12751682.1527087878000@Atlassian.JIRA>
References: <JIRA.12751682.1527087878000@Atlassian.JIRA>
	<JIRA.12751682.1527087878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751682.1527087878000.105182.1527780300530@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3027:
----------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/jbosstm/quickstart/pull/227


> Failing LRA quickstarts as Narayana still reports dependency at lra annotations
> -------------------------------------------------------------------------------
>
>                 Key: JBTM-3027
>                 URL: https://issues.jboss.org/browse/JBTM-3027
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> LRA quickstarts are failing ({{/home/ochaloup/Transactions/quickstart-jbosstm/rts/lra}}) because the fraction which is created from the {{lra-filters}} injects not only eclipse lra annotations but the narayana:lra-annotations dependency too.
> There is fail on the injections with errors like
> {code}
> 2018-05-23 16:56:41,684 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."lra-test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-test.war".WeldStartService: Failed to start service
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAClient with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private io.narayana.rts.lra.demo.flight.FlightService.lraClient
>   at io.narayana.rts.lra.demo.flight.FlightService.lraClient(FlightService.java:0)
>         at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
>         at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
>         at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
>         at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
>         at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
>         at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>         at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu May 31 11:25:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Thu, 31 May 2018 11:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3027) Failing LRA quickstarts
 as Narayana still reports dependency at lra annotations
In-Reply-To: <JIRA.12751682.1527087878000@Atlassian.JIRA>
References: <JIRA.12751682.1527087878000@Atlassian.JIRA>
	<JIRA.12751682.1527087878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12751682.1527087878000.105188.1527780300675@Atlassian.JIRA>


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

Ondra Chaloupka updated JBTM-3027:
----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Failing LRA quickstarts as Narayana still reports dependency at lra annotations
> -------------------------------------------------------------------------------
>
>                 Key: JBTM-3027
>                 URL: https://issues.jboss.org/browse/JBTM-3027
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.8.2.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> LRA quickstarts are failing ({{/home/ochaloup/Transactions/quickstart-jbosstm/rts/lra}}) because the fraction which is created from the {{lra-filters}} injects not only eclipse lra annotations but the narayana:lra-annotations dependency too.
> There is fail on the injections with errors like
> {code}
> 2018-05-23 16:56:41,684 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."lra-test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-test.war".WeldStartService: Failed to start service
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAClient with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private io.narayana.rts.lra.demo.flight.FlightService.lraClient
>   at io.narayana.rts.lra.demo.flight.FlightService.lraClient(FlightService.java:0)
>         at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
>         at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
>         at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
>         at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
>         at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
>         at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>         at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)