From issues at jboss.org  Fri Jul  1 09:54:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 1 Jul 2016 09:54:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2583) Use the local
 ActionStatusService to determine if a transaction containing XAResources is
 still in-flight before relying on orphan detection
In-Reply-To: <JIRA.12596411.1449836497000@Atlassian.JIRA>
References: <JIRA.12596411.1449836497000@Atlassian.JIRA>
	<JIRA.12596411.1449836497000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596411.1449836497000.81455.1467381240638@Atlassian.JIRA>


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

RH Bugzilla Integration commented on JBTM-2583:
-----------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 1310603|https://bugzilla.redhat.com/show_bug.cgi?id=1310603] from ON_QA to VERIFIED

> Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2583
>                 URL: https://issues.jboss.org/browse/JBTM-2583
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Recovery
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 4.17.34, 5.2.17.Final, 5.3.0.Final
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>  
> * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Jul  7 07:47:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 7 Jul 2016 07:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in
	Compensation API
In-Reply-To: <JIRA.12463204.1333527218000@Atlassian.JIRA>
References: <JIRA.12463204.1333527218000@Atlassian.JIRA>
	<JIRA.12463204.1333527218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463204.1333527218000.95463.1467892020385@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-1107:
----------------------------------
    Description: 
*Background*
Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash.

*Requirements*
# Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler).
## Require Serializable interface.
## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration).
# Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant).
## Make transaction identifier persistable (converting it to String should work).
## Implement PersistableParticipant in ParticipantImpl.
## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated.
# Make compensation scoped beans persistable.


  was:
Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers would be invoked in case of the system crash.
In addition, @CompensationScoped beans should be available during the recovery.




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



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul  8 08:36:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 8 Jul 2016 08:36:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart
	doesn't work
In-Reply-To: <JIRA.12638129.1467981304000@Atlassian.JIRA>
References: <JIRA.12638129.1467981304000@Atlassian.JIRA>
	<JIRA.12638129.1467981304124@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638129.1467981304000.100546.1467981360239@Atlassian.JIRA>

Gytis Trikleris created JBTM-2699:
-------------------------------------

             Summary: Simple RTS quickstart doesn't work
                 Key: JBTM-2699
                 URL: https://issues.jboss.org/browse/JBTM-2699
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Demonstrator, REST
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
             Fix For: 5.next


{code}
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1]
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul  8 08:36:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 8 Jul 2016 08:36:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart
	doesn't work
In-Reply-To: <JIRA.12638129.1467981304000@Atlassian.JIRA>
References: <JIRA.12638129.1467981304000@Atlassian.JIRA>
	<JIRA.12638129.1467981304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638129.1467981304000.100548.1467981360329@Atlassian.JIRA>


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

Work on JBTM-2699 started by Gytis Trikleris.
---------------------------------------------
> Simple RTS quickstart doesn't work
> ----------------------------------
>
>                 Key: JBTM-2699
>                 URL: https://issues.jboss.org/browse/JBTM-2699
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator, REST
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul  8 10:24:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 8 Jul 2016 10:24:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart
	doesn't work
In-Reply-To: <JIRA.12638129.1467981304000@Atlassian.JIRA>
References: <JIRA.12638129.1467981304000@Atlassian.JIRA>
	<JIRA.12638129.1467981304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638129.1467981304000.101312.1467987840278@Atlassian.JIRA>


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

Work on JBTM-2699 stopped by Gytis Trikleris.
---------------------------------------------
> Simple RTS quickstart doesn't work
> ----------------------------------
>
>                 Key: JBTM-2699
>                 URL: https://issues.jboss.org/browse/JBTM-2699
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator, REST
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul  8 10:24:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 8 Jul 2016 10:24:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart
	doesn't work
In-Reply-To: <JIRA.12638129.1467981304000@Atlassian.JIRA>
References: <JIRA.12638129.1467981304000@Atlassian.JIRA>
	<JIRA.12638129.1467981304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638129.1467981304000.101315.1467987840380@Atlassian.JIRA>


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

Gytis Trikleris reassigned JBTM-2699:
-------------------------------------

    Assignee: Michael Musgrove  (was: Gytis Trikleris)


> Simple RTS quickstart doesn't work
> ----------------------------------
>
>                 Key: JBTM-2699
>                 URL: https://issues.jboss.org/browse/JBTM-2699
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator, REST
>            Reporter: Gytis Trikleris
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 11 02:07:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Mon, 11 Jul 2016 02:07:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2695) Blacktie administration
 services test deployment fails
In-Reply-To: <JIRA.12635636.1467116848000@Atlassian.JIRA>
References: <JIRA.12635636.1467116848000@Atlassian.JIRA>
	<JIRA.12635636.1467116848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635636.1467116848000.104136.1468217220483@Atlassian.JIRA>


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

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


> Blacktie administration services test deployment fails
> ------------------------------------------------------
>
>                 Key: JBTM-2695
>                 URL: https://issues.jboss.org/browse/JBTM-2695
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: BlackTie
>            Reporter: Gytis Trikleris
>            Assignee: Amos Feng
>            Priority: Minor
>             Fix For: 5.next
>
>
> {code}
>  T E S T S
> -------------------------------------------------------
> Running AdvertiseUnadvertiseTest
> 20:38:01,608 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/data/content/65/36deb9697994d21be752edb6296e8d3ea4456f/content
> 20:38:01,662 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war")
> 20:38:02,983 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:02,999 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 12ms
> 20:38:03,036 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:03,037 INFO  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.32 sec <<< FAILURE! - in AdvertiseUnadvertiseTest
> AdvertiseUnadvertiseTest  Time elapsed: 7.319 sec  <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.Exception: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> 	at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Results :
> Tests in error: 
>   AdvertiseUnadvertiseTest.AdvertiseUnadvertiseTest ? Deployment Cannot deploy: ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Blacktie C++ Plugin ................................ SUCCESS [ 16.490 s]
> [INFO] BlackTie all files ................................. SUCCESS [  2.660 s]
> [INFO] Blacktie Defaults and Dependencies ................. SUCCESS [  0.096 s]
> [INFO] Blacktie C Defaults and Dependencies ............... SUCCESS [  7.708 s]
> [INFO] Blacktie Java JNI Tests ............................ SUCCESS [  3.153 s]
> [INFO] Blacktie Schemas ................................... SUCCESS [  2.247 s]
> [INFO] BlackTie Messaging (via JMS) ....................... SUCCESS [  5.733 s]
> [INFO] Blacktie Java XATMI Implementation ................. SUCCESS [05:37 min]
> [INFO] Blacktie Java NBF Implementation ................... SUCCESS [  4.431 s]
> [INFO] Blacktie Administration Services ................... FAILURE [ 52.390 s]
> [INFO] Blacktie Administration Services EAR ............... SKIPPED
> [INFO] Blacktie Core C++ Implementation ................... SKIPPED
> [INFO] Blacktie Codec C++ Implementation .................. SKIPPED
> [INFO] Blacktie C++ REST Transport ........................ SKIPPED
> [INFO] Blacktie Utilities ................................. SKIPPED
> [INFO] Blacktie C++ TX Client Library ..................... SKIPPED
> [INFO] Blacktie C++ Hybrid Transport ...................... SKIPPED
> [INFO] Blacktie C++ XATMI Implementation .................. SKIPPED
> [INFO] Blacktie C++ Queue Client .......................... SKIPPED
> [INFO] Blacktie NBF ....................................... SKIPPED
> [INFO] BlackTie Admin CLI Tool ............................ SKIPPED
> [INFO] Blacktie Server Code Generation .................... SKIPPED
> [INFO] Blacktie Java/C C/Java XATMI Tests ................. SKIPPED
> [INFO] Blacktie Distribution .............................. SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 07:36 min
> [INFO] Finished at: 2016-06-24T20:38:03+01:00
> [INFO] Final Memory: 60M/144M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project blacktie-admin-services: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/blacktie-admin-services/target/surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :blacktie-admin-services
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   21590 19887  0 20:30 ?        00:00:00 /bin/sh blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   21646 21590  6 20:30 ?        00:00:30 /usr/local/jdk1.8.0_60//bin/java -D[Standalone] -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties -jar /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar -mp /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   22528 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh: line 307: 21646 Killed                  "/usr/local/jdk1.8.0_60//bin/java" -D"[Standalone]" -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE "-Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone" '-c' 'standalone-blacktie.xml' '-Djboss.bind.address=localhost' '-Djboss.bind.address.unsecure=localhost' '-Djboss.bind.address.management=localhost'
> pkill: 2508 - Operation not permitted
> pkill: 1841 - Operation not permitted
> pkill: 3071 - Operation not permitted
> pkill: 1413 - Operation not permitted
> pkill: 1497 - Operation not permitted
> pkill: 1502 - Operation not permitted
> pkill: 1503 - Operation not permitted
> pkill: 1596 - Operation not permitted
> pkill: 2221 - Operation not permitted
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   22539 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> Some tests failed: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el5/1101/
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jul 11 02:17:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Mon, 11 Jul 2016 02:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the
 same package:javax/transaction
In-Reply-To: <JIRA.12617017.1461728855000@Atlassian.JIRA>
References: <JIRA.12617017.1461728855000@Atlassian.JIRA>
	<JIRA.12617017.1461728855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12617017.1461728855000.104201.1468217820140@Atlassian.JIRA>


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

Amos Feng resolved JBTM-2660.
-----------------------------
    Resolution: Done


> multiple jars provide the same package:javax/transaction
> --------------------------------------------------------
>
>                 Key: JBTM-2660
>                 URL: https://issues.jboss.org/browse/JBTM-2660
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Minor
>             Fix For: 5.next
>
>
> [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction
> Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning
> Package found in   [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec]
> Class path         [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 11 07:06:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Mon, 11 Jul 2016 07:06:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2689) narayana-osgi-jta
 integration test does not work with the karaf 4.x
In-Reply-To: <JIRA.12631965.1465977185000@Atlassian.JIRA>
References: <JIRA.12631965.1465977185000@Atlassian.JIRA>
	<JIRA.12631965.1465977185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12631965.1465977185000.105390.1468235160107@Atlassian.JIRA>


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

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


> narayana-osgi-jta integration test does not work with the karaf 4.x
> -------------------------------------------------------------------
>
>                 Key: JBTM-2689
>                 URL: https://issues.jboss.org/browse/JBTM-2689
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>
> The aquillian-container-karaf-embedded only support the karaf 2.3.3 and we are using the shell command with 4.x
> Now we just  disable the integration test temperately.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 11 23:24:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Mon, 11 Jul 2016 23:24:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2689) narayana-osgi-jta
 integration test does not work with the karaf 4.x
In-Reply-To: <JIRA.12631965.1465977185000@Atlassian.JIRA>
References: <JIRA.12631965.1465977185000@Atlassian.JIRA>
	<JIRA.12631965.1465977185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12631965.1465977185000.108716.1468293840203@Atlassian.JIRA>


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

Amos Feng commented on JBTM-2689:
---------------------------------

we need to use the arquillian-container-karaf-managed with 2.2.0-SNAPSHOT which support the karaf 4.0.4 currently

> narayana-osgi-jta integration test does not work with the karaf 4.x
> -------------------------------------------------------------------
>
>                 Key: JBTM-2689
>                 URL: https://issues.jboss.org/browse/JBTM-2689
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>
> The aquillian-container-karaf-embedded only support the karaf 2.3.3 and we are using the shell command with 4.x
> Now we just  disable the integration test temperately.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 12 02:40:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 12 Jul 2016 02:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2689) narayana-osgi-jta
 integration test does not work with the karaf 4.x
In-Reply-To: <JIRA.12631965.1465977185000@Atlassian.JIRA>
References: <JIRA.12631965.1465977185000@Atlassian.JIRA>
	<JIRA.12631965.1465977185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12631965.1465977185000.108868.1468305600341@Atlassian.JIRA>


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

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


> narayana-osgi-jta integration test does not work with the karaf 4.x
> -------------------------------------------------------------------
>
>                 Key: JBTM-2689
>                 URL: https://issues.jboss.org/browse/JBTM-2689
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>
> The aquillian-container-karaf-embedded only support the karaf 2.3.3 and we are using the shell command with 4.x
> Now we just  disable the integration test temperately.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 12 02:40:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 12 Jul 2016 02:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2689) narayana-osgi-jta
 integration test does not work with the karaf 4.x
In-Reply-To: <JIRA.12631965.1465977185000@Atlassian.JIRA>
References: <JIRA.12631965.1465977185000@Atlassian.JIRA>
	<JIRA.12631965.1465977185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12631965.1465977185000.108870.1468305600456@Atlassian.JIRA>


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

Amos Feng updated JBTM-2689:
----------------------------
    Fix Version/s: 5.next


> narayana-osgi-jta integration test does not work with the karaf 4.x
> -------------------------------------------------------------------
>
>                 Key: JBTM-2689
>                 URL: https://issues.jboss.org/browse/JBTM-2689
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The aquillian-container-karaf-embedded only support the karaf 2.3.3 and we are using the shell command with 4.x
> Now we just  disable the integration test temperately.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 12 02:43:00 2016
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 12 Jul 2016 02:43:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2695) Blacktie administration
 services test deployment fails
In-Reply-To: <JIRA.12635636.1467116848000@Atlassian.JIRA>
References: <JIRA.12635636.1467116848000@Atlassian.JIRA>
	<JIRA.12635636.1467116848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635636.1467116848000.108875.1468305780615@Atlassian.JIRA>


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

Amos Feng updated JBTM-2695:
----------------------------
    Priority: Major  (was: Minor)


> Blacktie administration services test deployment fails
> ------------------------------------------------------
>
>                 Key: JBTM-2695
>                 URL: https://issues.jboss.org/browse/JBTM-2695
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: BlackTie
>            Reporter: Gytis Trikleris
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> {code}
>  T E S T S
> -------------------------------------------------------
> Running AdvertiseUnadvertiseTest
> 20:38:01,608 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/data/content/65/36deb9697994d21be752edb6296e8d3ea4456f/content
> 20:38:01,662 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war")
> 20:38:02,983 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:02,999 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 12ms
> 20:38:03,036 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:03,037 INFO  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.32 sec <<< FAILURE! - in AdvertiseUnadvertiseTest
> AdvertiseUnadvertiseTest  Time elapsed: 7.319 sec  <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.Exception: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> 	at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Results :
> Tests in error: 
>   AdvertiseUnadvertiseTest.AdvertiseUnadvertiseTest ? Deployment Cannot deploy: ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Blacktie C++ Plugin ................................ SUCCESS [ 16.490 s]
> [INFO] BlackTie all files ................................. SUCCESS [  2.660 s]
> [INFO] Blacktie Defaults and Dependencies ................. SUCCESS [  0.096 s]
> [INFO] Blacktie C Defaults and Dependencies ............... SUCCESS [  7.708 s]
> [INFO] Blacktie Java JNI Tests ............................ SUCCESS [  3.153 s]
> [INFO] Blacktie Schemas ................................... SUCCESS [  2.247 s]
> [INFO] BlackTie Messaging (via JMS) ....................... SUCCESS [  5.733 s]
> [INFO] Blacktie Java XATMI Implementation ................. SUCCESS [05:37 min]
> [INFO] Blacktie Java NBF Implementation ................... SUCCESS [  4.431 s]
> [INFO] Blacktie Administration Services ................... FAILURE [ 52.390 s]
> [INFO] Blacktie Administration Services EAR ............... SKIPPED
> [INFO] Blacktie Core C++ Implementation ................... SKIPPED
> [INFO] Blacktie Codec C++ Implementation .................. SKIPPED
> [INFO] Blacktie C++ REST Transport ........................ SKIPPED
> [INFO] Blacktie Utilities ................................. SKIPPED
> [INFO] Blacktie C++ TX Client Library ..................... SKIPPED
> [INFO] Blacktie C++ Hybrid Transport ...................... SKIPPED
> [INFO] Blacktie C++ XATMI Implementation .................. SKIPPED
> [INFO] Blacktie C++ Queue Client .......................... SKIPPED
> [INFO] Blacktie NBF ....................................... SKIPPED
> [INFO] BlackTie Admin CLI Tool ............................ SKIPPED
> [INFO] Blacktie Server Code Generation .................... SKIPPED
> [INFO] Blacktie Java/C C/Java XATMI Tests ................. SKIPPED
> [INFO] Blacktie Distribution .............................. SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 07:36 min
> [INFO] Finished at: 2016-06-24T20:38:03+01:00
> [INFO] Final Memory: 60M/144M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project blacktie-admin-services: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/blacktie-admin-services/target/surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :blacktie-admin-services
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   21590 19887  0 20:30 ?        00:00:00 /bin/sh blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   21646 21590  6 20:30 ?        00:00:30 /usr/local/jdk1.8.0_60//bin/java -D[Standalone] -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties -jar /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar -mp /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   22528 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh: line 307: 21646 Killed                  "/usr/local/jdk1.8.0_60//bin/java" -D"[Standalone]" -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE "-Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone" '-c' 'standalone-blacktie.xml' '-Djboss.bind.address=localhost' '-Djboss.bind.address.unsecure=localhost' '-Djboss.bind.address.management=localhost'
> pkill: 2508 - Operation not permitted
> pkill: 1841 - Operation not permitted
> pkill: 3071 - Operation not permitted
> pkill: 1413 - Operation not permitted
> pkill: 1497 - Operation not permitted
> pkill: 1502 - Operation not permitted
> pkill: 1503 - Operation not permitted
> pkill: 1596 - Operation not permitted
> pkill: 2221 - Operation not permitted
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   22539 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> Some tests failed: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el5/1101/
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jul 12 09:13:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 12 Jul 2016 09:13:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2695) Blacktie administration
 services test deployment fails
In-Reply-To: <JIRA.12635636.1467116848000@Atlassian.JIRA>
References: <JIRA.12635636.1467116848000@Atlassian.JIRA>
	<JIRA.12635636.1467116848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635636.1467116848000.111135.1468329180104@Atlassian.JIRA>


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

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


> Blacktie administration services test deployment fails
> ------------------------------------------------------
>
>                 Key: JBTM-2695
>                 URL: https://issues.jboss.org/browse/JBTM-2695
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: BlackTie
>            Reporter: Gytis Trikleris
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> {code}
>  T E S T S
> -------------------------------------------------------
> Running AdvertiseUnadvertiseTest
> 20:38:01,608 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/data/content/65/36deb9697994d21be752edb6296e8d3ea4456f/content
> 20:38:01,662 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war")
> 20:38:02,983 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:02,999 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 12ms
> 20:38:03,036 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:03,037 INFO  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.32 sec <<< FAILURE! - in AdvertiseUnadvertiseTest
> AdvertiseUnadvertiseTest  Time elapsed: 7.319 sec  <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.Exception: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> 	at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Results :
> Tests in error: 
>   AdvertiseUnadvertiseTest.AdvertiseUnadvertiseTest ? Deployment Cannot deploy: ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Blacktie C++ Plugin ................................ SUCCESS [ 16.490 s]
> [INFO] BlackTie all files ................................. SUCCESS [  2.660 s]
> [INFO] Blacktie Defaults and Dependencies ................. SUCCESS [  0.096 s]
> [INFO] Blacktie C Defaults and Dependencies ............... SUCCESS [  7.708 s]
> [INFO] Blacktie Java JNI Tests ............................ SUCCESS [  3.153 s]
> [INFO] Blacktie Schemas ................................... SUCCESS [  2.247 s]
> [INFO] BlackTie Messaging (via JMS) ....................... SUCCESS [  5.733 s]
> [INFO] Blacktie Java XATMI Implementation ................. SUCCESS [05:37 min]
> [INFO] Blacktie Java NBF Implementation ................... SUCCESS [  4.431 s]
> [INFO] Blacktie Administration Services ................... FAILURE [ 52.390 s]
> [INFO] Blacktie Administration Services EAR ............... SKIPPED
> [INFO] Blacktie Core C++ Implementation ................... SKIPPED
> [INFO] Blacktie Codec C++ Implementation .................. SKIPPED
> [INFO] Blacktie C++ REST Transport ........................ SKIPPED
> [INFO] Blacktie Utilities ................................. SKIPPED
> [INFO] Blacktie C++ TX Client Library ..................... SKIPPED
> [INFO] Blacktie C++ Hybrid Transport ...................... SKIPPED
> [INFO] Blacktie C++ XATMI Implementation .................. SKIPPED
> [INFO] Blacktie C++ Queue Client .......................... SKIPPED
> [INFO] Blacktie NBF ....................................... SKIPPED
> [INFO] BlackTie Admin CLI Tool ............................ SKIPPED
> [INFO] Blacktie Server Code Generation .................... SKIPPED
> [INFO] Blacktie Java/C C/Java XATMI Tests ................. SKIPPED
> [INFO] Blacktie Distribution .............................. SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 07:36 min
> [INFO] Finished at: 2016-06-24T20:38:03+01:00
> [INFO] Final Memory: 60M/144M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project blacktie-admin-services: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/blacktie-admin-services/target/surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :blacktie-admin-services
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   21590 19887  0 20:30 ?        00:00:00 /bin/sh blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   21646 21590  6 20:30 ?        00:00:30 /usr/local/jdk1.8.0_60//bin/java -D[Standalone] -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties -jar /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar -mp /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   22528 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh: line 307: 21646 Killed                  "/usr/local/jdk1.8.0_60//bin/java" -D"[Standalone]" -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE "-Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone" '-c' 'standalone-blacktie.xml' '-Djboss.bind.address=localhost' '-Djboss.bind.address.unsecure=localhost' '-Djboss.bind.address.management=localhost'
> pkill: 2508 - Operation not permitted
> pkill: 1841 - Operation not permitted
> pkill: 3071 - Operation not permitted
> pkill: 1413 - Operation not permitted
> pkill: 1497 - Operation not permitted
> pkill: 1502 - Operation not permitted
> pkill: 1503 - Operation not permitted
> pkill: 1596 - Operation not permitted
> pkill: 2221 - Operation not permitted
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   22539 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> Some tests failed: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el5/1101/
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jul 12 09:13:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 12 Jul 2016 09:13:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2695) Blacktie administration
 services test deployment fails
In-Reply-To: <JIRA.12635636.1467116848000@Atlassian.JIRA>
References: <JIRA.12635636.1467116848000@Atlassian.JIRA>
	<JIRA.12635636.1467116848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635636.1467116848000.111138.1468329180272@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2695:
-------------------------------------

Pull was actually merged

> Blacktie administration services test deployment fails
> ------------------------------------------------------
>
>                 Key: JBTM-2695
>                 URL: https://issues.jboss.org/browse/JBTM-2695
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: BlackTie
>            Reporter: Gytis Trikleris
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> {code}
>  T E S T S
> -------------------------------------------------------
> Running AdvertiseUnadvertiseTest
> 20:38:01,608 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/data/content/65/36deb9697994d21be752edb6296e8d3ea4456f/content
> 20:38:01,662 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war")
> 20:38:02,983 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:02,999 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 12ms
> 20:38:03,036 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 20:38:03,037 INFO  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.32 sec <<< FAILURE! - in AdvertiseUnadvertiseTest
> AdvertiseUnadvertiseTest  Time elapsed: 7.319 sec  <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.Exception: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> 	at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Results :
> Tests in error: 
>   AdvertiseUnadvertiseTest.AdvertiseUnadvertiseTest ? Deployment Cannot deploy: ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Blacktie C++ Plugin ................................ SUCCESS [ 16.490 s]
> [INFO] BlackTie all files ................................. SUCCESS [  2.660 s]
> [INFO] Blacktie Defaults and Dependencies ................. SUCCESS [  0.096 s]
> [INFO] Blacktie C Defaults and Dependencies ............... SUCCESS [  7.708 s]
> [INFO] Blacktie Java JNI Tests ............................ SUCCESS [  3.153 s]
> [INFO] Blacktie Schemas ................................... SUCCESS [  2.247 s]
> [INFO] BlackTie Messaging (via JMS) ....................... SUCCESS [  5.733 s]
> [INFO] Blacktie Java XATMI Implementation ................. SUCCESS [05:37 min]
> [INFO] Blacktie Java NBF Implementation ................... SUCCESS [  4.431 s]
> [INFO] Blacktie Administration Services ................... FAILURE [ 52.390 s]
> [INFO] Blacktie Administration Services EAR ............... SKIPPED
> [INFO] Blacktie Core C++ Implementation ................... SKIPPED
> [INFO] Blacktie Codec C++ Implementation .................. SKIPPED
> [INFO] Blacktie C++ REST Transport ........................ SKIPPED
> [INFO] Blacktie Utilities ................................. SKIPPED
> [INFO] Blacktie C++ TX Client Library ..................... SKIPPED
> [INFO] Blacktie C++ Hybrid Transport ...................... SKIPPED
> [INFO] Blacktie C++ XATMI Implementation .................. SKIPPED
> [INFO] Blacktie C++ Queue Client .......................... SKIPPED
> [INFO] Blacktie NBF ....................................... SKIPPED
> [INFO] BlackTie Admin CLI Tool ............................ SKIPPED
> [INFO] Blacktie Server Code Generation .................... SKIPPED
> [INFO] Blacktie Java/C C/Java XATMI Tests ................. SKIPPED
> [INFO] Blacktie Distribution .............................. SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 07:36 min
> [INFO] Finished at: 2016-06-24T20:38:03+01:00
> [INFO] Final Memory: 60M/144M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project blacktie-admin-services: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/blacktie-admin-services/target/surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :blacktie-admin-services
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   21590 19887  0 20:30 ?        00:00:00 /bin/sh blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   21646 21590  6 20:30 ?        00:00:30 /usr/local/jdk1.8.0_60//bin/java -D[Standalone] -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties -jar /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar -mp /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost
> hudson   22528 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh: line 307: 21646 Killed                  "/usr/local/jdk1.8.0_60//bin/java" -D"[Standalone]" -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE "-Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone" '-c' 'standalone-blacktie.xml' '-Djboss.bind.address=localhost' '-Djboss.bind.address.unsecure=localhost' '-Djboss.bind.address.management=localhost'
> pkill: 2508 - Operation not permitted
> pkill: 1841 - Operation not permitted
> pkill: 3071 - Operation not permitted
> pkill: 1413 - Operation not permitted
> pkill: 1497 - Operation not permitted
> pkill: 1502 - Operation not permitted
> pkill: 1503 - Operation not permitted
> pkill: 1596 - Operation not permitted
> pkill: 2221 - Operation not permitted
> UID        PID  PPID  C STIME TTY          TIME CMD
> hudson    8757  8755  0 Apr12 ?        00:22:38 sshd: hudson at notty
> hudson    8835  8757  0 Apr12 ?        00:00:00 bash -c cd "/home/hudson" && java  -jar slave.jar
> hudson    8852  8835  0 Apr12 ?        01:03:45 java -jar slave.jar
> hudson    9476 32418  0 Apr12 ?        00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin
> hudson   14629     1  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   14655 14629  0 Apr08 ?        00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh
> hudson   19882  8852  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   19887 19882  0 20:07 ?        00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh
> hudson   22539 19887  0 20:38 ?        00:00:00 ps -f
> hudson   32418 14655  0 Apr12 ?        00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp  -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false
> Some tests failed: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el5/1101/
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jul 12 10:41:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 12 Jul 2016 10:41:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2700) Change quickstart poms to
 run tests and scripts
In-Reply-To: <JIRA.12638525.1468334405000@Atlassian.JIRA>
References: <JIRA.12638525.1468334405000@Atlassian.JIRA>
	<JIRA.12638525.1468334405599@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638525.1468334405000.111826.1468334460184@Atlassian.JIRA>

Michael Musgrove created JBTM-2700:
--------------------------------------

             Summary: Change quickstart poms to run tests and scripts
                 Key: JBTM-2700
                 URL: https://issues.jboss.org/browse/JBTM-2700
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Demonstrator
    Affects Versions: 5.3.3.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove


Change quickstart poms to run tests and scripts



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 13 11:49:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 13 Jul 2016 11:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart
	doesn't work
In-Reply-To: <JIRA.12638129.1467981304000@Atlassian.JIRA>
References: <JIRA.12638129.1467981304000@Atlassian.JIRA>
	<JIRA.12638129.1467981304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638129.1467981304000.117733.1468424940179@Atlassian.JIRA>


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

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


> Simple RTS quickstart doesn't work
> ----------------------------------
>
>                 Key: JBTM-2699
>                 URL: https://issues.jboss.org/browse/JBTM-2699
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator, REST
>            Reporter: Gytis Trikleris
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 13 13:35:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 13 Jul 2016 13:35:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart
	doesn't work
In-Reply-To: <JIRA.12638129.1467981304000@Atlassian.JIRA>
References: <JIRA.12638129.1467981304000@Atlassian.JIRA>
	<JIRA.12638129.1467981304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638129.1467981304000.120941.1468431300376@Atlassian.JIRA>


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

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


> Simple RTS quickstart doesn't work
> ----------------------------------
>
>                 Key: JBTM-2699
>                 URL: https://issues.jboss.org/browse/JBTM-2699
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator, REST
>            Reporter: Gytis Trikleris
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 14 08:29:00 2016
From: issues at jboss.org (Tom Ross (JIRA))
Date: Thu, 14 Jul 2016 08:29:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499305000@Atlassian.JIRA>
References: <JIRA.12638854.1468499305000@Atlassian.JIRA>
	<JIRA.12638854.1468499305523@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499305000.123395.1468499340383@Atlassian.JIRA>

Tom Ross created JBTM-2701:
------------------------------

             Summary: XAR should be scanned more frequently for prepared transactions
                 Key: JBTM-2701
                 URL: https://issues.jboss.org/browse/JBTM-2701
             Project: JBoss Transaction Manager
          Issue Type: Feature Request
          Components: Transaction Core
    Affects Versions: 4.17.33
         Environment: JBoss EA P6.4.8
            Reporter: Tom Ross


Under heavy load it is possible that XAR is not scanned and as a result a prepared transaction is not included in the list and subsequent commit will fail.

The following signature can be observed in the log file:
{quote}2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 14 08:30:01 2016
From: issues at jboss.org (Tom Ross (JIRA))
Date: Thu, 14 Jul 2016 08:30:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.123407.1468499401112@Atlassian.JIRA>


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

Tom Ross updated JBTM-2701:
---------------------------
    Description: 
Under heavy load it is possible that XAR is not scanned and as a result a prepared transaction is not included in the list and subsequent commit will fail.

The following signature can be observed in the log file:
{noformat}
2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
{noformat}

  was:
Under heavy load it is possible that XAR is not scanned and as a result a prepared transaction is not included in the list and subsequent commit will fail.

The following signature can be observed in the log file:
{quote}2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
{quote}



> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>
> Under heavy load it is possible that XAR is not scanned and as a result a prepared transaction is not included in the list and subsequent commit will fail.
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 14 10:00:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 14 Jul 2016 10:00:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.123981.1468504801251@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2701:
--------------------------------
    Description: 
The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).

The following signature can be observed in the log file:
{noformat}
2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
{noformat}

It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.

  was:
Under heavy load it is possible that XAR is not scanned and as a result a prepared transaction is not included in the list and subsequent commit will fail.

The following signature can be observed in the log file:
{noformat}
2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
{noformat}



> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 14 10:00:03 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 14 Jul 2016 10:00:03 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.123983.1468504803710@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2701:
--------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 14 10:00:05 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 14 Jul 2016 10:00:05 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.123986.1468504805060@Atlassian.JIRA>


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

Tom Jenkinson reassigned JBTM-2701:
-----------------------------------

    Assignee: Amos Feng


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 14 10:00:06 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 14 Jul 2016 10:00:06 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.123994.1468504806092@Atlassian.JIRA>


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

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


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 15 05:24:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 15 Jul 2016 05:24:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.127101.1468574640160@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2701:
-------------------------------------

Problem is observed in following scenario:

{code}
1. prepare XAR1
2. commit XAR1
4. getNewXAResource
5. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES
6. prepare XAR2
7. commit XAR2
8. getNewXAResource
9. periodicFirstPass not called as not IDLE so no scan XAR2
{code}

We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass.

> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 15 05:40:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 15 Jul 2016 05:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in
	Compensation API
In-Reply-To: <JIRA.12463204.1333527218000@Atlassian.JIRA>
References: <JIRA.12463204.1333527218000@Atlassian.JIRA>
	<JIRA.12463204.1333527218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463204.1333527218000.127132.1468575600480@Atlassian.JIRA>


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

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



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 19 10:22:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 19 Jul 2016 10:22:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2122) Go through JTS code and
 compare/contrast with capabilities missing in other dist tx code we've got
In-Reply-To: <JIRA.12534664.1394544075000@Atlassian.JIRA>
References: <JIRA.12534664.1394544075000@Atlassian.JIRA>
	<JIRA.12534664.1394544075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534664.1394544075000.140524.1468938120207@Atlassian.JIRA>


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

Michael Musgrove reassigned JBTM-2122:
--------------------------------------

    Assignee: Michael Musgrove  (was: Mark Little)


> Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2122
>                 URL: https://issues.jboss.org/browse/JBTM-2122
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: JTS
>    Affects Versions: 5.0.1
>            Reporter: Mark Little
>            Assignee: Michael Musgrove
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 20 04:16:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 20 Jul 2016 04:16:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.144038.1469002560763@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2701:
-------------------------------------

Try to look in the existing RecoveryXid map first.

> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 20 04:44:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 20 Jul 2016 04:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2678) @TxLogged annotation does
	not work
In-Reply-To: <JIRA.12627714.1464098858000@Atlassian.JIRA>
References: <JIRA.12627714.1464098858000@Atlassian.JIRA>
	<JIRA.12627714.1464098858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627714.1464098858000.144265.1469004240391@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2678:
-------------------------------------

[~paul.robinson] - any comment?

> @TxLogged annotation does not work
> ----------------------------------
>
>                 Key: JBTM-2678
>                 URL: https://issues.jboss.org/browse/JBTM-2678
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa58158c5e3ac6a#diff-a01554d0172e1da7703c5134820edb6aL124



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 20 12:02:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Wed, 20 Jul 2016 12:02:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check
 Glassfish-to-Narayana interoperability (via JTS).
In-Reply-To: <JIRA.12603200.1455037791000@Atlassian.JIRA>
References: <JIRA.12603200.1455037791000@Atlassian.JIRA>
	<JIRA.12603200.1455037791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603200.1455037791000.148594.1469030520780@Atlassian.JIRA>


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

Michael Musgrove edited comment on JBTM-2623 at 7/20/16 12:01 PM:
------------------------------------------------------------------

I am in the process of creating a quickstart in my own private branch that patches the blockers (https://github.com/mmusgrov/quickstart-1/tree/JBTM-223/interop) and demonstrates interoperability. The README.md file describes how to apply 3 patch file to fix the blockers (wildfly, glassfish and narayana) and how to deploy and run the example EJBs.


was (Author: mmusgrov):
I have created a branch that fixes the blockers (https://github.com/jbosstm/narayana/tree/JBTM-223/interop) and also a wilfly branch that removes the EJB interceptor that blocks the import of foreign transactions (https://github.com/jbosstm/jboss-as/tree/5_BRANCH_JBTM-223). The interop/README.md file in the JBTM-223 branch describes how to test transaction propagation and recovery.

> Check Glassfish-to-Narayana interoperability (via JTS).
> -------------------------------------------------------
>
>                 Key: JBTM-2623
>                 URL: https://issues.jboss.org/browse/JBTM-2623
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: JTS
>    Affects Versions: 5.2.13.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS).
> Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL.
> \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279]
> XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown:
> {quote}
> javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process
>         at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695)
>         at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61)
>         at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30)
>         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:483)
>         at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377)
>         at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352)
>         at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399)
>         at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55)
>         at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330)
>         at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62)
>         at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753)
>         at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701)
>         at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588)
>         at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255)
>         at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251)
>         at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968)
>         at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597)
>         at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360)
>         at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356)
>         at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
>         at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138)
>         at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
>         at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216)
>         at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211)
>         at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
>         at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73)
>         at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24)
>         at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
>         at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
>         at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
>         at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48)
>         at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
>         at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
>         at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226)
>         at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418)
>         at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
>         at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200)
>         at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
>         at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240)
>         at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
>         at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
>         at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210)
>         at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118)
>         at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
>         at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:483)
>         at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
>         at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
>         at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
>         at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
>         at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
>         at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
>         at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
>         at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
>         at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)
>         at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
>         at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)
>         at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)
>         at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)
>         at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
>         at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
>         at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
>         at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
>         at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
>         at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
>         at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
>         at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
>         at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
>         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
>         at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 20 15:47:00 2016
From: issues at jboss.org (Mark Little (JIRA))
Date: Wed, 20 Jul 2016 15:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2702) Place a copy of getpids
	in ext directory
In-Reply-To: <JIRA.12639968.1469043986000@Atlassian.JIRA>
References: <JIRA.12639968.1469043986000@Atlassian.JIRA>
	<JIRA.12639968.1469043986607@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639968.1469043986000.149636.1469044020085@Atlassian.JIRA>

Mark Little created JBTM-2702:
---------------------------------

             Summary: Place a copy of getpids in ext directory
                 Key: JBTM-2702
                 URL: https://issues.jboss.org/browse/JBTM-2702
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: Transaction Core
    Affects Versions: 5.3.3.Final
            Reporter: Mark Little
            Assignee: Mark Little
            Priority: Minor


We offer getpids as an implementation option for ExecProcessId and refer people to download it from the original site. Should keep a cached copy locally just in case it vanishes. Make sure licence is clearly displayed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 20 15:51:00 2016
From: issues at jboss.org (Mark Little (JIRA))
Date: Wed, 20 Jul 2016 15:51:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2702) Place a copy of getpids
	in ext directory
In-Reply-To: <JIRA.12639968.1469043987000@Atlassian.JIRA>
References: <JIRA.12639968.1469043987000@Atlassian.JIRA>
	<JIRA.12639968.1469043987000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639968.1469043987000.149639.1469044260486@Atlassian.JIRA>


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

Work on JBTM-2702 started by Mark Little.
-----------------------------------------
> Place a copy of getpids in ext directory
> ----------------------------------------
>
>                 Key: JBTM-2702
>                 URL: https://issues.jboss.org/browse/JBTM-2702
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Transaction Core
>    Affects Versions: 5.3.3.Final
>            Reporter: Mark Little
>            Assignee: Mark Little
>            Priority: Minor
>
> We offer getpids as an implementation option for ExecProcessId and refer people to download it from the original site. Should keep a cached copy locally just in case it vanishes. Make sure licence is clearly displayed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 20 15:51:00 2016
From: issues at jboss.org (Mark Little (JIRA))
Date: Wed, 20 Jul 2016 15:51:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2702) Place a copy of getpids
	in ext directory
In-Reply-To: <JIRA.12639968.1469043987000@Atlassian.JIRA>
References: <JIRA.12639968.1469043987000@Atlassian.JIRA>
	<JIRA.12639968.1469043987000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639968.1469043987000.149642.1469044260563@Atlassian.JIRA>


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

Mark Little closed JBTM-2702.
-----------------------------
    Resolution: Done


> Place a copy of getpids in ext directory
> ----------------------------------------
>
>                 Key: JBTM-2702
>                 URL: https://issues.jboss.org/browse/JBTM-2702
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Transaction Core
>    Affects Versions: 5.3.3.Final
>            Reporter: Mark Little
>            Assignee: Mark Little
>            Priority: Minor
>
> We offer getpids as an implementation option for ExecProcessId and refer people to download it from the original site. Should keep a cached copy locally just in case it vanishes. Make sure licence is clearly displayed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:16:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:16:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-396) Provide one-phase commit
 optimization for WS-TX
In-Reply-To: <JIRA.12366478.1219954111000@Atlassian.JIRA>
References: <JIRA.12366478.1219954111000@Atlassian.JIRA>
	<JIRA.12366478.1219954111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12366478.1219954111000.155131.1469110560405@Atlassian.JIRA>


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

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


> Provide one-phase commit optimization for WS-TX
> -----------------------------------------------
>
>                 Key: JBTM-396
>                 URL: https://issues.jboss.org/browse/JBTM-396
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: XTS
>    Affects Versions: 4.4.CR1
>            Reporter: Mark Little
>            Priority: Minor
>
> WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled.
> Discussion currently happening here: https://community.jboss.org/message/831313



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:16:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:16:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-396) Provide one-phase commit
 optimization for WS-TX
In-Reply-To: <JIRA.12366478.1219954111000@Atlassian.JIRA>
References: <JIRA.12366478.1219954111000@Atlassian.JIRA>
	<JIRA.12366478.1219954111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12366478.1219954111000.155135.1469110560514@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-396:
-------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> Provide one-phase commit optimization for WS-TX
> -----------------------------------------------
>
>                 Key: JBTM-396
>                 URL: https://issues.jboss.org/browse/JBTM-396
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: XTS
>    Affects Versions: 4.4.CR1
>            Reporter: Mark Little
>            Priority: Minor
>
> WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled.
> Discussion currently happening here: https://community.jboss.org/message/831313



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:17:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-410) implement mixed outcome
	support for XTS
In-Reply-To: <JIRA.12368764.1223285866000@Atlassian.JIRA>
References: <JIRA.12368764.1223285866000@Atlassian.JIRA>
	<JIRA.12368764.1223285866000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12368764.1223285866000.155144.1469110620339@Atlassian.JIRA>


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

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


> implement mixed outcome support for XTS
> ---------------------------------------
>
>                 Key: JBTM-410
>                 URL: https://issues.jboss.org/browse/JBTM-410
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: XTS
>    Affects Versions: 4.4.0.GA
>            Reporter: Jonathan Halliday
>            Priority: Optional
>             Fix For: 6.later
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:18:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:18:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-809) Provide instructions for
 using ironjacamar as well as transactional driver
In-Reply-To: <JIRA.12421618.1287482188000@Atlassian.JIRA>
References: <JIRA.12421618.1287482188000@Atlassian.JIRA>
	<JIRA.12421618.1287482188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12421618.1287482188000.155155.1469110680591@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-809:
-------------------------------
    Issue Type: Task  (was: Feature Request)


> Provide instructions for using ironjacamar as well as transactional driver
> --------------------------------------------------------------------------
>
>                 Key: JBTM-809
>                 URL: https://issues.jboss.org/browse/JBTM-809
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Resource Manager
>            Reporter: Tom Jenkinson
>
> Supporting the transactional driver source code on the face of it duplicates much effort with the IronJacamar team. Supporting IronJacamar for datasource access should be possible as this is the connection manager in the Application Server and it provides an embedded mode for use outside of the application server.
> There are several bugs open against transactional driver that will be resolved by completing this work.
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
>         InitialContext initialContext = new InitialContext();
>         UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
>         DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL()); 
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
>   May have to provide these both upfront.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:18:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:18:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-809) Provide instructions for
 using ironjacamar as well as transactional driver
In-Reply-To: <JIRA.12421618.1287482188000@Atlassian.JIRA>
References: <JIRA.12421618.1287482188000@Atlassian.JIRA>
	<JIRA.12421618.1287482188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12421618.1287482188000.155168.1469110681219@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-809:
-------------------------------
    Description: 
The general approach would be along the lines of:

Startup
======
Embedded embedded = EmbeddedFactory.create();
embedded.startup();
embedded.deploy(new File("my-rar.rar").toURI().toURL());
embedded.deploy(new File("my-ds.xml").toURI().toURL());

In use
=====
        InitialContext initialContext = new InitialContext();
        UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
        DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");

Shutdown
=======
embedded.undeploy(new File("my-ds.xml").toURI().toURL()); 
embedded.undeploy(new File("my-rar.rar").toURI().toURL());
embedded.shutdown(); // does not work - some threads don't stop

Problems?
=========
JCA transitive dependencies?
Accessing ds files from war?
Accessing rar from war?
  May have to provide these both upfront.

  was:
Supporting the transactional driver source code on the face of it duplicates much effort with the IronJacamar team. Supporting IronJacamar for datasource access should be possible as this is the connection manager in the Application Server and it provides an embedded mode for use outside of the application server.

There are several bugs open against transactional driver that will be resolved by completing this work.




The general approach would be along the lines of:

Startup
======
Embedded embedded = EmbeddedFactory.create();
embedded.startup();
embedded.deploy(new File("my-rar.rar").toURI().toURL());
embedded.deploy(new File("my-ds.xml").toURI().toURL());

In use
=====
        InitialContext initialContext = new InitialContext();
        UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
        DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");

Shutdown
=======
embedded.undeploy(new File("my-ds.xml").toURI().toURL()); 
embedded.undeploy(new File("my-rar.rar").toURI().toURL());
embedded.shutdown(); // does not work - some threads don't stop

Problems?
=========
JCA transitive dependencies?
Accessing ds files from war?
Accessing rar from war?
  May have to provide these both upfront.



> Provide instructions for using ironjacamar as well as transactional driver
> --------------------------------------------------------------------------
>
>                 Key: JBTM-809
>                 URL: https://issues.jboss.org/browse/JBTM-809
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Resource Manager
>            Reporter: Tom Jenkinson
>
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
>         InitialContext initialContext = new InitialContext();
>         UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
>         DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL()); 
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
>   May have to provide these both upfront.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:21:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:21:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-809) Provide instructions for
 using ironjacamar as well as transactional driver
In-Reply-To: <JIRA.12421618.1287482188000@Atlassian.JIRA>
References: <JIRA.12421618.1287482188000@Atlassian.JIRA>
	<JIRA.12421618.1287482188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12421618.1287482188000.155181.1469110860991@Atlassian.JIRA>


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

Tom Jenkinson resolved JBTM-809.
--------------------------------
    Fix Version/s: 5.3.3.Final
         Assignee: Gytis Trikleris
       Resolution: Done


> Provide instructions for using ironjacamar as well as transactional driver
> --------------------------------------------------------------------------
>
>                 Key: JBTM-809
>                 URL: https://issues.jboss.org/browse/JBTM-809
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Resource Manager
>            Reporter: Tom Jenkinson
>            Assignee: Gytis Trikleris
>             Fix For: 5.3.3.Final
>
>
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
>         InitialContext initialContext = new InitialContext();
>         UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
>         DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL()); 
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
>   May have to provide these both upfront.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:21:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:21:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-809) Provide instructions for
 using ironjacamar as well as transactional driver
In-Reply-To: <JIRA.12421618.1287482188000@Atlassian.JIRA>
References: <JIRA.12421618.1287482188000@Atlassian.JIRA>
	<JIRA.12421618.1287482188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12421618.1287482188000.155186.1469110861115@Atlassian.JIRA>


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

Tom Jenkinson closed JBTM-809.
------------------------------


> Provide instructions for using ironjacamar as well as transactional driver
> --------------------------------------------------------------------------
>
>                 Key: JBTM-809
>                 URL: https://issues.jboss.org/browse/JBTM-809
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Resource Manager
>            Reporter: Tom Jenkinson
>            Assignee: Gytis Trikleris
>             Fix For: 5.3.3.Final
>
>
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
>         InitialContext initialContext = new InitialContext();
>         UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
>         DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL()); 
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
>   May have to provide these both upfront.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:22:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:22:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-845) Datagrid Objectstore
In-Reply-To: <JIRA.12438360.1306400873000@Atlassian.JIRA>
References: <JIRA.12438360.1306400873000@Atlassian.JIRA>
	<JIRA.12438360.1306400873000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12438360.1306400873000.155190.1469110920153@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-845:
-------------------------------
    Summary: Datagrid Objectstore  (was: Cloud ObjectStore)


> Datagrid Objectstore
> --------------------
>
>                 Key: JBTM-845
>                 URL: https://issues.jboss.org/browse/JBTM-845
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Recovery
>            Reporter: Tom Jenkinson
>
> Create an objectstore that uses infinispan or jgroups for replication of volatile data



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:25:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-845) Datagrid Objectstore
In-Reply-To: <JIRA.12438360.1306400873000@Atlassian.JIRA>
References: <JIRA.12438360.1306400873000@Atlassian.JIRA>
	<JIRA.12438360.1306400873000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12438360.1306400873000.155218.1469111100189@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-845:
-------------------------------
    Forum Reference: https://developer.jboss.org/thread/242346?start=0&tstart=0


> Datagrid Objectstore
> --------------------
>
>                 Key: JBTM-845
>                 URL: https://issues.jboss.org/browse/JBTM-845
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Recovery
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> Create an objectstore that uses infinispan or jgroups for replication of volatile data



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:25:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-845) Datagrid Objectstore
In-Reply-To: <JIRA.12438360.1306400873000@Atlassian.JIRA>
References: <JIRA.12438360.1306400873000@Atlassian.JIRA>
	<JIRA.12438360.1306400873000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12438360.1306400873000.155216.1469111100142@Atlassian.JIRA>


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

Tom Jenkinson resolved JBTM-845.
--------------------------------
      Assignee: Tom Jenkinson
    Resolution: Won't Fix


James Brearly did analysis on this in his thesis and the outcome was that split brain would severely impact the comprehensiveness of the solution.

> Datagrid Objectstore
> --------------------
>
>                 Key: JBTM-845
>                 URL: https://issues.jboss.org/browse/JBTM-845
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Recovery
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> Create an objectstore that uses infinispan or jgroups for replication of volatile data



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:25:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-845) Datagrid Objectstore
In-Reply-To: <JIRA.12438360.1306400873000@Atlassian.JIRA>
References: <JIRA.12438360.1306400873000@Atlassian.JIRA>
	<JIRA.12438360.1306400873000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12438360.1306400873000.155220.1469111100237@Atlassian.JIRA>


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

Tom Jenkinson closed JBTM-845.
------------------------------


> Datagrid Objectstore
> --------------------
>
>                 Key: JBTM-845
>                 URL: https://issues.jboss.org/browse/JBTM-845
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Recovery
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> Create an objectstore that uses infinispan or jgroups for replication of volatile data



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:28:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:28:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-974) Allow callback invocation
 for multiple business method invocations
In-Reply-To: <JIRA.12453175.1322481045000@Atlassian.JIRA>
References: <JIRA.12453175.1322481045000@Atlassian.JIRA>
	<JIRA.12453175.1322481045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453175.1322481045000.155237.1469111280978@Atlassian.JIRA>


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

Gytis Trikleris closed JBTM-974.
--------------------------------
    Fix Version/s:     (was: 6.later)
       Resolution: Out of Date


> Allow callback invocation for multiple business method invocations
> ------------------------------------------------------------------
>
>                 Key: JBTM-974
>                 URL: https://issues.jboss.org/browse/JBTM-974
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Compensations
>            Reporter: Paul Robinson
>              Labels: TXFramework
>
> By setting the 'single' attribute on a Lifecycle Handler Annotation (such as @Prepare or @Compensate) identifies whether more than one callback can be registered for the lifecycle method in response to multiple invocations of the ServiceRequest method. If it is true then the lifecycle method will be called once to the ServiceRequest method. If it is false then the lifecycle method will be called once in response to each (non-read only) call to the ServiceRequest method. The default is 'false'.
> Annotation:
> {code}
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
> public @interface Compensate
> {
>     public boolean single() default false;
> }
> {code}
> Example:
> {code}
> @ServiceRequest
> public void addToBasket()
> {
>   //Add another item to the basket.
> }
> @Compensate(single=true)
> public void emptyBasket()
> {
>   //Empty every item from the basket
> }
> {code}
> In this example the @ServiceRequest may be invoked many times to add many items to the basket. The @Compensate method is only needed to be invoked once as the basket can be emptied in one operation. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:28:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:28:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1801) Move all test properties
	into root pom.xml
In-Reply-To: <JIRA.12495127.1372236069000@Atlassian.JIRA>
References: <JIRA.12495127.1372236069000@Atlassian.JIRA>
	<JIRA.12495127.1372236069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495127.1372236069000.155251.1469111281391@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-1801:
--------------------------------
    Issue Type: Task  (was: Feature Request)


> Move all test properties into root pom.xml
> ------------------------------------------
>
>                 Key: JBTM-1801
>                 URL: https://issues.jboss.org/browse/JBTM-1801
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Trivial
>             Fix For: 5.later
>
>
> We have these test properties duplicated in many places:
> https://github.com/jbosstm/narayana/blob/master/XTS/localjunit/pom.xml#L22
> We should move them up to the root pom.xml to simplify maintenance. As part of this task you need to hunt out all these usages and similar. Then come up with a common set of properties that works in all cases and move to the root pom.xml.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:28:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:28:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2594) Link some doc chapters at
 higher levels on the project site
In-Reply-To: <JIRA.12597930.1451329348000@Atlassian.JIRA>
References: <JIRA.12597930.1451329348000@Atlassian.JIRA>
	<JIRA.12597930.1451329348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597930.1451329348000.155258.1469111281644@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2594:
--------------------------------
    Issue Type: Task  (was: Feature Request)


> Link some doc chapters at higher levels on the project site
> -----------------------------------------------------------
>
>                 Key: JBTM-2594
>                 URL: https://issues.jboss.org/browse/JBTM-2594
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Documentation
>    Affects Versions: 5.2.11.Final
>            Reporter: Mark Little
>
> On the main Narayana site (http://narayana.io) we call out the higher level components such as JTA, STM, Orb Portability etc. However, on the docs page (http://narayana.io/documentation/index.html), apart from Blacktie the reader needs to load and read through the entire doc (or manually search) for the relevant sections. Maybe link the relevant chapters (such as http://narayana.io/docs/project/index.html#d0e16062) in the docs pages and/or the top level of the site, so someone looking for the JTS or STM docs can click there immediately.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:28:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:28:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1789) Simplify deploy plugin
 configuration and don't deploy uber (shaded) jars
In-Reply-To: <JIRA.12494787.1371743096000@Atlassian.JIRA>
References: <JIRA.12494787.1371743096000@Atlassian.JIRA>
	<JIRA.12494787.1371743096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494787.1371743096000.155248.1469111281336@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-1789:
--------------------------------
    Issue Type: Task  (was: Feature Request)


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



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:29:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:29:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1575) Test support for Informix
In-Reply-To: <JIRA.12487777.1363956541000@Atlassian.JIRA>
References: <JIRA.12487777.1363956541000@Atlassian.JIRA>
	<JIRA.12487777.1363956541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487777.1363956541000.155261.1469111340299@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-1575:
--------------------------------
    Component/s:     (was: Testing)


> Test support for Informix
> -------------------------
>
>                 Key: JBTM-1575
>                 URL: https://issues.jboss.org/browse/JBTM-1575
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: BlackTie
>            Reporter: Michael Musgrove
>            Priority: Optional
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:29:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:29:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1974) Qa tests needs the
 narayana build being done with parameter idlj-enabled to work
In-Reply-To: <JIRA.12502747.1381471594000@Atlassian.JIRA>
References: <JIRA.12502747.1381471594000@Atlassian.JIRA>
	<JIRA.12502747.1381471594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502747.1381471594000.155263.1469111340363@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-1974:
--------------------------------
    Issue Type: Task  (was: Feature Request)


> Qa tests needs the narayana build being done with parameter idlj-enabled to work
> --------------------------------------------------------------------------------
>
>                 Key: JBTM-1974
>                 URL: https://issues.jboss.org/browse/JBTM-1974
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Testing
>    Affects Versions: 5.0.0.M5
>            Reporter: Ondra Chaloupka
>            Priority: Minor
>
> When qa tests should be built without compilation errors the prior narayana build has to be run with parameter -Didlj-enabled=true
> In the way like
> ./build.sh clean install -Prelease -DskipTests -Didlj-enabled=true
> This fact should be at least documented in REAME.
> Plus it would be nice to avoid this dependence (or put idlj-enabled parameter which activates a profile as default).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:31:02 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:31:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1582) Investigate support for
 XA from C in Posgres
In-Reply-To: <JIRA.12402940.1264507472000@Atlassian.JIRA>
References: <JIRA.12402940.1264507472000@Atlassian.JIRA>
	<JIRA.12402940.1264507472000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12402940.1264507472000.155270.1469111462534@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-1582:
--------------------------------
    Component/s:     (was: Resource Manager)


> Investigate support for XA from C in Posgres
> --------------------------------------------
>
>                 Key: JBTM-1582
>                 URL: https://issues.jboss.org/browse/JBTM-1582
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>
> As requested by Juergen in the forums: http://community.jboss.org/message/522272#522272



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:32:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:32:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1576) Introduce a JBoss
 deployable artifact for the C++ XATMI services
In-Reply-To: <JIRA.12379297.1234017611000@Atlassian.JIRA>
References: <JIRA.12379297.1234017611000@Atlassian.JIRA>
	<JIRA.12379297.1234017611000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12379297.1234017611000.155275.1469111520392@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-1576:
--------------------------------
    Component/s:     (was: Tooling)


> Introduce a JBoss deployable artifact for the C++ XATMI services
> ----------------------------------------------------------------
>
>                 Key: JBTM-1576
>                 URL: https://issues.jboss.org/browse/JBTM-1576
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>         Attachments: onmessage.tgz
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Currently the XATMI services must be deployed in the standalone "Server" CORBA container
> It is expected to be advantageous to support the deployment of the services into JBoss for ease of management and performance.
> It is expected that the user will deploy a .war file containing a btconfig.xml defining the .so/.dll (also contained in the .war).
> BlackTie java code will read the btconfig.xml and calculate the path of the .so based on the place that AS7 unzips war files to during deployment PLUS the path defined in the users btconfig.xml
> If AS7 does not explode war files during deployment, it will not be possible for the user to package their .so in their .war file (I don't think - please do investigate this) and so a java.native.library.path will need defining at boot time and the user will need to place all their jni code in there thereby not supporting hot deploy unfortunately but still gaining the benefits of performance (not requiring socket comms between java and C).
> Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services deployed into the AS to use the existing JCA connections



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:32:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:32:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1576) Introduce a JBoss
 deployable artifact for the C++ XATMI services
In-Reply-To: <JIRA.12379297.1234017611000@Atlassian.JIRA>
References: <JIRA.12379297.1234017611000@Atlassian.JIRA>
	<JIRA.12379297.1234017611000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12379297.1234017611000.155279.1469111520533@Atlassian.JIRA>


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

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


> Introduce a JBoss deployable artifact for the C++ XATMI services
> ----------------------------------------------------------------
>
>                 Key: JBTM-1576
>                 URL: https://issues.jboss.org/browse/JBTM-1576
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Priority: Minor
>         Attachments: onmessage.tgz
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Currently the XATMI services must be deployed in the standalone "Server" CORBA container
> It is expected to be advantageous to support the deployment of the services into JBoss for ease of management and performance.
> It is expected that the user will deploy a .war file containing a btconfig.xml defining the .so/.dll (also contained in the .war).
> BlackTie java code will read the btconfig.xml and calculate the path of the .so based on the place that AS7 unzips war files to during deployment PLUS the path defined in the users btconfig.xml
> If AS7 does not explode war files during deployment, it will not be possible for the user to package their .so in their .war file (I don't think - please do investigate this) and so a java.native.library.path will need defining at boot time and the user will need to place all their jni code in there thereby not supporting hot deploy unfortunately but still gaining the benefits of performance (not requiring socket comms between java and C).
> Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services deployed into the AS to use the existing JCA connections



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:34:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:34:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1680) Allow 2PC participants to
 enlist in a compensation-based transaction
In-Reply-To: <JIRA.12491225.1367933829000@Atlassian.JIRA>
References: <JIRA.12491225.1367933829000@Atlassian.JIRA>
	<JIRA.12491225.1367933829000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491225.1367933829000.155313.1469111641371@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-1680:
----------------------------------
    Component/s: Compensations
                     (was: XTS)
                     (was: TXFramework)


> Allow 2PC participants to enlist in a compensation-based transaction
> --------------------------------------------------------------------
>
>                 Key: JBTM-1680
>                 URL: https://issues.jboss.org/browse/JBTM-1680
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Compensations
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 6.later
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate.
> This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:38:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:38:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-979) Support REST-JDI protocol
 in the TXFramework
In-Reply-To: <JIRA.12453191.1322487691000@Atlassian.JIRA>
References: <JIRA.12453191.1322487691000@Atlassian.JIRA>
	<JIRA.12453191.1322487691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453191.1322487691000.155328.1469111880638@Atlassian.JIRA>


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

Gytis Trikleris closed JBTM-979.
--------------------------------
    Fix Version/s:     (was: 6.later)
       Resolution: Rejected


>  Support REST-JDI protocol in the TXFramework
> ---------------------------------------------
>
>                 Key: JBTM-979
>                 URL: https://issues.jboss.org/browse/JBTM-979
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: TXFramework
>            Reporter: Paul Robinson
>            Priority: Optional
>              Labels: TXFramework
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:38:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:38:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1030) Async commit feature in
	TXFramework
In-Reply-To: <JIRA.12457345.1327417317000@Atlassian.JIRA>
References: <JIRA.12457345.1327417317000@Atlassian.JIRA>
	<JIRA.12457345.1327417317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457345.1327417317000.155345.1469111881278@Atlassian.JIRA>


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

Gytis Trikleris closed JBTM-1030.
---------------------------------
    Resolution: Rejected


> Async commit feature in TXFramework
> -----------------------------------
>
>                 Key: JBTM-1030
>                 URL: https://issues.jboss.org/browse/JBTM-1030
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: TXFramework
>            Reporter: Paul Robinson
>            Priority: Minor
>
> It would be handy to provide an asynchronous commit feature. This would allow a thread to continue whilst the transaction protocol proceeds. A callback handler can be registered to handle the outcome.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:40:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1718) Resolve the
 ParticipantCompletion race condition
In-Reply-To: <JIRA.12492789.1369643112000@Atlassian.JIRA>
References: <JIRA.12492789.1369643112000@Atlassian.JIRA>
	<JIRA.12492789.1369643112000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492789.1369643112000.155355.1469112000335@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-1718:
----------------------------------
    Component/s: Compensations
                     (was: TXFramework)


> Resolve the ParticipantCompletion race condition
> ------------------------------------------------
>
>                 Key: JBTM-1718
>                 URL: https://issues.jboss.org/browse/JBTM-1718
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Paul Robinson
>
> This issue is documented here: JBTM-1429
> In the documentation for JBTM-1429, we state that this issue is unlikely to happen in a distributed environment. This is true, however, the Compensations API is designed to work local-only as well as distributed over WS-BA. Therefore it is much more likely to happen in a production environment.
> Therefore we need to remove this race condition. It can be done in a proprietary mannor as we are not interoperating with another implementation ion local-only mode. When distributing the transaction we fall back to the standard protocol that is susceptible to the race condition. However, as we stated in the docs, this condition is unlikely to manifest in a distributed environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:40:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 21 Jul 2016 10:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement
 TransactionalDriver alternative for JMS
In-Reply-To: <JIRA.12607685.1456397929000@Atlassian.JIRA>
References: <JIRA.12607685.1456397929000@Atlassian.JIRA>
	<JIRA.12607685.1456397929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607685.1456397929000.155357.1469112000410@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2629:
--------------------------------
    Component/s: Transactional Driver


> Implement TransactionalDriver alternative for JMS
> -------------------------------------------------
>
>                 Key: JBTM-2629
>                 URL: https://issues.jboss.org/browse/JBTM-2629
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: Transactional Driver
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>
> JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:40:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:40:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1715) NPE when using
 CompensationManager within an in-flowed WS-BA transaction
In-Reply-To: <JIRA.12492763.1369581852000@Atlassian.JIRA>
References: <JIRA.12492763.1369581852000@Atlassian.JIRA>
	<JIRA.12492763.1369581852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492763.1369581852000.155360.1469112000570@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-1715:
----------------------------------
    Component/s: Compensations
                     (was: TXFramework)


> NPE when using CompensationManager within an in-flowed WS-BA transaction
> ------------------------------------------------------------------------
>
>                 Key: JBTM-1715
>                 URL: https://issues.jboss.org/browse/JBTM-1715
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 5.later
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction.
> {quote}
> 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100]
> ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS
> HOT]
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:41:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:41:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1167) WS-BA TXFramework
 quickstart should use @ConfirmCompleted to send email
In-Reply-To: <JIRA.12466775.1337351409000@Atlassian.JIRA>
References: <JIRA.12466775.1337351409000@Atlassian.JIRA>
	<JIRA.12466775.1337351409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466775.1337351409000.155379.1469112060953@Atlassian.JIRA>


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

Gytis Trikleris closed JBTM-1167.
---------------------------------
    Resolution: Rejected


> WS-BA TXFramework quickstart should use @ConfirmCompleted to send email
> -----------------------------------------------------------------------
>
>                 Key: JBTM-1167
>                 URL: https://issues.jboss.org/browse/JBTM-1167
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: TXFramework
>            Reporter: Paul Robinson
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There is a bug in this quickstart. The email is sent in the 'placeOrder' method. If a crash occurs after the email is sent, but before XTS writes the recovery record, then a compensate will not be triggered. You should wait until an @ConfirmCompleted method is invoked (with parameter of 'true') is invoked. This is confirmation that the XTS recovery record was written and a final outcome is guaranteed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:42:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:42:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1052) Support Web services with
 a webservices.xml present in TXFramework
In-Reply-To: <JIRA.12458382.1328522425000@Atlassian.JIRA>
References: <JIRA.12458382.1328522425000@Atlassian.JIRA>
	<JIRA.12458382.1328522425000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458382.1328522425000.155386.1469112120379@Atlassian.JIRA>


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

Gytis Trikleris closed JBTM-1052.
---------------------------------
    Fix Version/s:     (was: 6.later)
       Resolution: Rejected


> Support Web services with a webservices.xml present in TXFramework
> ------------------------------------------------------------------
>
>                 Key: JBTM-1052
>                 URL: https://issues.jboss.org/browse/JBTM-1052
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: TXFramework
>            Reporter: Paul Robinson
>            Priority: Minor
>
> See: https://community.jboss.org/message/714478#714478



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:42:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:42:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1006) Review TXFramework test
	coverage
In-Reply-To: <JIRA.12454575.1323701457000@Atlassian.JIRA>
References: <JIRA.12454575.1323701457000@Atlassian.JIRA>
	<JIRA.12454575.1323701457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454575.1323701457000.155389.1469112120489@Atlassian.JIRA>


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

Gytis Trikleris resolved JBTM-1006.
-----------------------------------
    Resolution: Rejected


> Review TXFramework test coverage
> --------------------------------
>
>                 Key: JBTM-1006
>                 URL: https://issues.jboss.org/browse/JBTM-1006
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: TXFramework
>    Affects Versions: 4.17.0.M1/5.0.0.M1
>            Reporter: Paul Robinson
>            Priority: Trivial
>
> Only the obvious "happy path" cases are tested at the moment. Need to ensure incorrect developer implementation and configuration is handled correctly.
> We should also consider taking a copy of the existing XTS tests and modify to use the TXFramework. This could allow us to get some good coverage, relatively quickly. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:42:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:42:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-987) Document Compensations API
In-Reply-To: <JIRA.12453232.1322502924000@Atlassian.JIRA>
References: <JIRA.12453232.1322502924000@Atlassian.JIRA>
	<JIRA.12453232.1322502924000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453232.1322502924000.155398.1469112120710@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-987:
---------------------------------
    Component/s: Compensations
                     (was: TXFramework)


> Document Compensations API
> --------------------------
>
>                 Key: JBTM-987
>                 URL: https://issues.jboss.org/browse/JBTM-987
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Compensations, Documentation
>            Reporter: Tom Jenkinson
>            Assignee: Paul Robinson
>            Priority: Optional
>              Labels: TXFramework
>             Fix For: 5.later
>
>
> Should cover all existing features and provide a skeleton for the final document.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:43:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 21 Jul 2016 10:43:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2221) Remove old TXFramework API
In-Reply-To: <JIRA.12545772.1404756219000@Atlassian.JIRA>
References: <JIRA.12545772.1404756219000@Atlassian.JIRA>
	<JIRA.12545772.1404756219000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545772.1404756219000.155401.1469112180382@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-2221:
----------------------------------
    Component/s: Compensations
                     (was: TXFramework)


> Remove old TXFramework API
> --------------------------
>
>                 Key: JBTM-2221
>                 URL: https://issues.jboss.org/browse/JBTM-2221
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Compensations
>            Reporter: Tom Jenkinson
>            Assignee: Paul Robinson
>             Fix For: 6.later
>
>
> This is now replaced by the CDI based Compensations API.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:48:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 21 Jul 2016 10:48:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1575) Test support for Informix
In-Reply-To: <JIRA.12487777.1363956541000@Atlassian.JIRA>
References: <JIRA.12487777.1363956541000@Atlassian.JIRA>
	<JIRA.12487777.1363956541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487777.1363956541000.155435.1469112480380@Atlassian.JIRA>


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

Michael Musgrove closed JBTM-1575.
----------------------------------
    Resolution: Duplicate


> Test support for Informix
> -------------------------
>
>                 Key: JBTM-1575
>                 URL: https://issues.jboss.org/browse/JBTM-1575
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: BlackTie
>            Reporter: Michael Musgrove
>            Priority: Optional
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:50:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 21 Jul 2016 10:50:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1109) JTA -> REST-AT Bridge
In-Reply-To: <JIRA.12463207.1333527295000@Atlassian.JIRA>
References: <JIRA.12463207.1333527295000@Atlassian.JIRA>
	<JIRA.12463207.1333527295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463207.1333527295000.155448.1469112600187@Atlassian.JIRA>


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

Michael Musgrove commented on JBTM-1109:
----------------------------------------

Changing priority to optional because we have not had any demand from the community for this feature

> JTA -> REST-AT Bridge
> ---------------------
>
>                 Key: JBTM-1109
>                 URL: https://issues.jboss.org/browse/JBTM-1109
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: REST, TxBridge
>            Reporter: Paul Robinson
>             Fix For: 6.later
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:50:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 21 Jul 2016 10:50:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1109) JTA -> REST-AT Bridge
In-Reply-To: <JIRA.12463207.1333527295000@Atlassian.JIRA>
References: <JIRA.12463207.1333527295000@Atlassian.JIRA>
	<JIRA.12463207.1333527295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463207.1333527295000.155452.1469112600430@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-1109:
-----------------------------------
    Priority: Optional  (was: Major)


> JTA -> REST-AT Bridge
> ---------------------
>
>                 Key: JBTM-1109
>                 URL: https://issues.jboss.org/browse/JBTM-1109
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: REST, TxBridge
>            Reporter: Paul Robinson
>            Priority: Optional
>             Fix For: 6.later
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 21 10:57:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 21 Jul 2016 10:57:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1468) Support pure-JTA client
 and server for WS-AT and REST-AT
In-Reply-To: <JIRA.12484910.1360853576000@Atlassian.JIRA>
References: <JIRA.12484910.1360853576000@Atlassian.JIRA>
	<JIRA.12484910.1360853576000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484910.1360853576000.155501.1469113020429@Atlassian.JIRA>


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

Michael Musgrove commented on JBTM-1468:
----------------------------------------

Items 3 and 4 have already been implemented.
Item 1 needs clarification from [~paul.robinson]

> Support pure-JTA client and server for WS-AT and REST-AT
> --------------------------------------------------------
>
>                 Key: JBTM-1468
>                 URL: https://issues.jboss.org/browse/JBTM-1468
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: REST, XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 6.later
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT.
> To do this we need to:
> # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations.
> # Client side JTA->REST-AT bridge. Needs implementing.
> # Server side REST-AT->JTA bridge. Needs integrating into code base.
> # Update the TXBridge quickstarts to use this and move them out.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 04:03:01 2016
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Fri, 22 Jul 2016 04:03:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2122) Go through JTS code and
 compare/contrast with capabilities missing in other dist tx code we've got
In-Reply-To: <JIRA.12534664.1394544075000@Atlassian.JIRA>
References: <JIRA.12534664.1394544075000@Atlassian.JIRA>
	<JIRA.12534664.1394544075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534664.1394544075000.157968.1469174581671@Atlassian.JIRA>


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

Ondra Chaloupka commented on JBTM-2122:
---------------------------------------

[~tomjenkinson] Not fully sure if our discussion at https://issues.jboss.org/browse/JBEAP-610?focusedCommentId=13147405#comment-13147405 is directly connected to this issue but you previous comments seem to me so. What I remember by [~hhovsepy]'s investigation it seemed that JTS works with 2pc for propagated transactions at any time (meaning even with one resource enlisted). Later on that was found that we have (?) some trouble in test and 1pc is used.

Your reference of https://c.na7.visual.force.com/apex/Case_View?sbstr=01560781 seems to me not related as it's rather caused by the fact discussing at https://issues.jboss.org/browse/JBEAP-225 and https://issues.jboss.org/browse/WFLY-4608 which is based on issue in container.

> Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2122
>                 URL: https://issues.jboss.org/browse/JBTM-2122
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: JTS
>    Affects Versions: 5.0.1
>            Reporter: Mark Little
>            Assignee: Michael Musgrove
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 05:42:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 05:42:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is
 committed at the same instance as a resource adapter/remote EJB calls
 XAT::recover() then you can get an NPE
In-Reply-To: <JIRA.12640258.1469180491000@Atlassian.JIRA>
References: <JIRA.12640258.1469180491000@Atlassian.JIRA>
	<JIRA.12640258.1469180491099@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640258.1469180491000.158644.1469180521766@Atlassian.JIRA>

Tom Jenkinson created JBTM-2703:
-----------------------------------

             Summary: When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
                 Key: JBTM-2703
                 URL: https://issues.jboss.org/browse/JBTM-2703
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: JCA
            Reporter: Tom Jenkinson
             Fix For: 5.next






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 05:44:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 05:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is
 committed at the same instance as a resource adapter/remote EJB calls
 XAT::recover() then you can get an NPE
In-Reply-To: <JIRA.12640258.1469180491000@Atlassian.JIRA>
References: <JIRA.12640258.1469180491000@Atlassian.JIRA>
	<JIRA.12640258.1469180491000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640258.1469180491000.158655.1469180640884@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2703:
--------------------------------
    Description: 
INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
ERROR [stderr] java.io.IOException: java.lang.NullPointerException
ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
ERROR [stderr] Caused by: java.lang.NullPointerException
ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
ERROR [stderr] 	... 10 more


> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2703
>                 URL: https://issues.jboss.org/browse/JBTM-2703
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Tom Jenkinson
>             Fix For: 5.next
>
>
> INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] 	... 10 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 05:44:02 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 05:44:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is
 committed at the same instance as a resource adapter/remote EJB calls
 XAT::recover() then you can get an NPE
In-Reply-To: <JIRA.12640258.1469180491000@Atlassian.JIRA>
References: <JIRA.12640258.1469180491000@Atlassian.JIRA>
	<JIRA.12640258.1469180491000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640258.1469180491000.158658.1469180642633@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2703:
--------------------------------
    Description: 
{code}
INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
ERROR [stderr] java.io.IOException: java.lang.NullPointerException
ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
ERROR [stderr] Caused by: java.lang.NullPointerException
ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
ERROR [stderr] 	... 10 more
{code}

  was:
INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
ERROR [stderr] java.io.IOException: java.lang.NullPointerException
ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
ERROR [stderr] Caused by: java.lang.NullPointerException
ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
ERROR [stderr] 	... 10 more



> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2703
>                 URL: https://issues.jboss.org/browse/JBTM-2703
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Tom Jenkinson
>             Fix For: 5.next
>
>
> {code}
> INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] 	... 10 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 05:44:02 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 05:44:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is
 committed at the same instance as a resource adapter/remote EJB calls
 XAT::recover() then you can get an NPE
In-Reply-To: <JIRA.12640258.1469180491000@Atlassian.JIRA>
References: <JIRA.12640258.1469180491000@Atlassian.JIRA>
	<JIRA.12640258.1469180491000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640258.1469180491000.158659.1469180642677@Atlassian.JIRA>


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

Tom Jenkinson reassigned JBTM-2703:
-----------------------------------

    Assignee: Tom Jenkinson


> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2703
>                 URL: https://issues.jboss.org/browse/JBTM-2703
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next
>
>
> {code}
> INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] 	... 10 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 06:23:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 06:23:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is
 committed at the same instance as a resource adapter/remote EJB calls
 XAT::recover() then you can get an NPE
In-Reply-To: <JIRA.12640258.1469180491000@Atlassian.JIRA>
References: <JIRA.12640258.1469180491000@Atlassian.JIRA>
	<JIRA.12640258.1469180491000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640258.1469180491000.158892.1469182980100@Atlassian.JIRA>


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

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


> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2703
>                 URL: https://issues.jboss.org/browse/JBTM-2703
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next
>
>
> {code}
> INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] 	... 10 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 06:32:01 2016
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Fri, 22 Jul 2016 06:32:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2122) Go through JTS code and
 compare/contrast with capabilities missing in other dist tx code we've got
In-Reply-To: <JIRA.12534664.1394544075000@Atlassian.JIRA>
References: <JIRA.12534664.1394544075000@Atlassian.JIRA>
	<JIRA.12534664.1394544075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534664.1394544075000.158929.1469183521040@Atlassian.JIRA>


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

Ondra Chaloupka edited comment on JBTM-2122 at 7/22/16 6:31 AM:
----------------------------------------------------------------

[~tomjenkinson] Not fully sure if our discussion at https://issues.jboss.org/browse/JBEAP-610?focusedCommentId=13147405#comment-13147405 is directly connected to this issue but you previous comments seem to me so. What I remember by [~hhovsepy]'s investigation it seemed that JTS works with 2pc for propagated transactions at any time (meaning even with one resource enlisted). Later on that was found that we have (?) some trouble in test and 1pc is used.

Your reference of https://c.na7.visual.force.com/apex/Case_View?sbstr=01560781 seems to me not related as it's rather caused by the fact discussing at https://issues.jboss.org/browse/JBEAP-225 and https://issues.jboss.org/browse/WFLY-4608 which is based on issue in container.

_plus as action item from f2f I would say that what you mentions in your first comment is not so. if we are not wrong in our settings then jts and jboss remoting run 1pc_


was (Author: ochaloup):
[~tomjenkinson] Not fully sure if our discussion at https://issues.jboss.org/browse/JBEAP-610?focusedCommentId=13147405#comment-13147405 is directly connected to this issue but you previous comments seem to me so. What I remember by [~hhovsepy]'s investigation it seemed that JTS works with 2pc for propagated transactions at any time (meaning even with one resource enlisted). Later on that was found that we have (?) some trouble in test and 1pc is used.

Your reference of https://c.na7.visual.force.com/apex/Case_View?sbstr=01560781 seems to me not related as it's rather caused by the fact discussing at https://issues.jboss.org/browse/JBEAP-225 and https://issues.jboss.org/browse/WFLY-4608 which is based on issue in container.

> Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2122
>                 URL: https://issues.jboss.org/browse/JBTM-2122
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: JTS
>    Affects Versions: 5.0.1
>            Reporter: Mark Little
>            Assignee: Michael Musgrove
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 07:53:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 22 Jul 2016 07:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2103) ORB-less JTS
In-Reply-To: <JIRA.12533245.1393338356000@Atlassian.JIRA>
References: <JIRA.12533245.1393338356000@Atlassian.JIRA>
	<JIRA.12533245.1393338356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533245.1393338356000.159357.1469188380294@Atlassian.JIRA>


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

Michael Musgrove closed JBTM-2103.
----------------------------------
    Resolution: Won't Fix


This topic came up during our latest F2F: we must continue to interoperate with legacy application servers so will be retaining JTS for that purpose. For vendors that decide not to implement RMI over IIOP we will not be proposing any alternative. We will, however, continue to investigate other options for interoperability (such as googles RPC framework, for example) in the linked JIRA (JBTM-2122).

> ORB-less JTS
> ------------
>
>                 Key: JBTM-2103
>                 URL: https://issues.jboss.org/browse/JBTM-2103
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>          Components: JTS
>    Affects Versions: 5.0.0
>            Reporter: Mark Little
>            Assignee: Michael Musgrove
>             Fix For: 6.later
>
>
> At some point in the future there's a good chance that the ORB requirement will be removed from EE entirely. If that happens we need to be able to react and ensure that the JTS continues to work because it?s the most complete distributed transaction implementation that we possess. Now there are two ways to do that:
> (i) we ship our own ORB, either JacORB or something else, say.
> (ii) we remove the dependency on CORBA entirely.
> Whilst (i) is a good short term option, I think we need to look at (ii). An old in-house TM that JBoss had which Narayana replaced had a JTS implementation  which supported CORBA and JBoss Remoting (I think it was Remoting). Ultimately what we need is a high performance distributed transactions implementation and JTS is it today but it has a dependency on CORBA that we need to try to remove and yet keep most of the non-ORB generated code/dependencies.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Jul 22 08:25:00 2016
From: issues at jboss.org (Paul Robinson (JIRA))
Date: Fri, 22 Jul 2016 08:25:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2678) @TxLogged annotation does
	not work
In-Reply-To: <JIRA.12627714.1464098858000@Atlassian.JIRA>
References: <JIRA.12627714.1464098858000@Atlassian.JIRA>
	<JIRA.12627714.1464098858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627714.1464098858000.159633.1469190300161@Atlassian.JIRA>


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

Paul Robinson commented on JBTM-2678:
-------------------------------------

If I recall correctly:

The @TxLogged handler is used as a callback for when the TM has written the transaction log. It's a pretty low level callback and was used as a workaround in certain use-cases where a failure-window might occur. However, i think I concluded that the workaround never actually closes any failure windows, it just moves it around. The correct thing to do is to bridge each phase of the compensation transaction to a JTA transaction. The TM then ensures no failure windows exist.

If you need a better understanding I can go into more detail. Maybe with a whiteboard at hand.

> @TxLogged annotation does not work
> ----------------------------------
>
>                 Key: JBTM-2678
>                 URL: https://issues.jboss.org/browse/JBTM-2678
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa58158c5e3ac6a#diff-a01554d0172e1da7703c5134820edb6aL124



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 10:13:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 10:13:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.160348.1469196780560@Atlassian.JIRA>


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

Tom Jenkinson edited comment on JBTM-2701 at 7/22/16 10:12 AM:
---------------------------------------------------------------

Problem is observed in following scenario:

{code}
0. prepare SAA1
1. prepare XAR1
2. getNewXAResource
3. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES
4. commit XAR1
5. prepare XAR2
6. commit XAR2
7. getNewXAResource
8. periodicFirstPass not called as not IDLE so no scan XAR2
{code}

We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass.


was (Author: tomjenkinson):
Problem is observed in following scenario:

{code}
1. prepare XAR1
2. commit XAR1
4. getNewXAResource
5. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES
6. prepare XAR2
7. commit XAR2
8. getNewXAResource
9. periodicFirstPass not called as not IDLE so no scan XAR2
{code}

We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass.

> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 11:51:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 11:51:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.161137.1469202661338@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2701:
-------------------------------------

I don't see why this: server.log.3:2016-06-28 12:18:33,041 WARN  [com.arjuna.ats.jta] (EJB default - 62) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/netconfresource >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/netconfresource com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e > happens and needs to replace the existing in memory version. Still debugging.

> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 22 17:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 22 Jul 2016 17:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.162222.1469224560048@Atlassian.JIRA>


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

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


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 04:57:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 25 Jul 2016 04:57:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437009000@Atlassian.JIRA>
References: <JIRA.12640451.1469437009000@Atlassian.JIRA>
	<JIRA.12640451.1469437009880@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437009000.5168.1469437021277@Atlassian.JIRA>

Gytis Trikleris created JBTM-2704:
-------------------------------------

             Summary: Compensations framework cannot instantiate bean from ear archive
                 Key: JBTM-2704
                 URL: https://issues.jboss.org/browse/JBTM-2704
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Compensations
            Reporter: Gytis Trikleris
             Fix For: 5.next


BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 04:57:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 25 Jul 2016 04:57:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.5170.1469437021709@Atlassian.JIRA>


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

Gytis Trikleris reassigned JBTM-2704:
-------------------------------------

    Assignee: Gytis Trikleris


> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 05:01:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 25 Jul 2016 05:01:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.5187.1469437260330@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-2704:
----------------------------------
    Forum Reference: https://developer.jboss.org/thread/271273, https://developer.jboss.org/message/960078


> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 05:01:00 2016
From: issues at jboss.org (Jive JIRA Integration (JIRA))
Date: Mon, 25 Jul 2016 05:01:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.5190.1469437260580@Atlassian.JIRA>


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

Jive JIRA Integration updated JBTM-2704:
----------------------------------------
    Forum Reference: https://developer.jboss.org/message/959371#959371, https://developer.jboss.org/thread/271273, https://developer.jboss.org/message/960078  (was: https://developer.jboss.org/thread/271273, https://developer.jboss.org/message/960078)


> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 05:01:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 25 Jul 2016 05:01:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.5203.1469437261588@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-2704:
----------------------------------
    Forum Reference: https://developer.jboss.org/message/959371#959371  (was: https://developer.jboss.org/message/959371#959371, https://developer.jboss.org/thread/271273, https://developer.jboss.org/message/960078)


> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 05:33:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 25 Jul 2016 05:33:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.5569.1469439180471@Atlassian.JIRA>


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

Work on JBTM-2704 started by Gytis Trikleris.
---------------------------------------------
> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jul 25 10:47:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 25 Jul 2016 10:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.8196.1469458020346@Atlassian.JIRA>


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

Issue was automatically transitioned when Gytis Trikleris created pull request #47 in GitHub
--------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Coding In Progress)


> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 06:05:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 26 Jul 2016 06:05:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2705) Investigate alternatives
 to encoding recovery data in RecoveryCoordinator IORs
In-Reply-To: <JIRA.12640621.1469527443000@Atlassian.JIRA>
References: <JIRA.12640621.1469527443000@Atlassian.JIRA>
	<JIRA.12640621.1469527443952@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640621.1469527443000.12359.1469527500305@Atlassian.JIRA>

Michael Musgrove created JBTM-2705:
--------------------------------------

             Summary: Investigate alternatives to encoding recovery data in RecoveryCoordinator IORs
                 Key: JBTM-2705
                 URL: https://issues.jboss.org/browse/JBTM-2705
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: JTS
    Affects Versions: 5.3.3.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


During JTS resource enlistment we create a RecoveryCoordinator IOR and embed recovery information in the ObjectKey part. This is not a portable solution since we need to use ORB vendor specific APIs to modify the ObjectKey. It would be preferable if we could use something that is in the CORBA specs that will work for all ORBs such as Portable Intercpeors (http://www.omg.org/cgi-bin/doc?ptc/2001-03-04).

Note that there is no current solution for IBM orb.





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 06:08:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 26 Jul 2016 06:08:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2705) Investigate alternatives
 to encoding recovery data in RecoveryCoordinator IORs
In-Reply-To: <JIRA.12640621.1469527444000@Atlassian.JIRA>
References: <JIRA.12640621.1469527444000@Atlassian.JIRA>
	<JIRA.12640621.1469527444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640621.1469527444000.12397.1469527680562@Atlassian.JIRA>


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

Michael Musgrove updated JBTM-2705:
-----------------------------------
        Parent: JBTM-2110
    Issue Type: Sub-task  (was: Task)


> Investigate alternatives to encoding recovery data in RecoveryCoordinator IORs
> ------------------------------------------------------------------------------
>
>                 Key: JBTM-2705
>                 URL: https://issues.jboss.org/browse/JBTM-2705
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: JTS
>    Affects Versions: 5.3.3.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> During JTS resource enlistment we create a RecoveryCoordinator IOR and embed recovery information in the ObjectKey part. This is not a portable solution since we need to use ORB vendor specific APIs to modify the ObjectKey. It would be preferable if we could use something that is in the CORBA specs that will work for all ORBs such as Portable Intercpeors (http://www.omg.org/cgi-bin/doc?ptc/2001-03-04).
> Note that there is no current solution for IBM orb.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 06:17:01 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 26 Jul 2016 06:17:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2706) Verify that we can run on
 the IBM JVM with OpenJDK
In-Reply-To: <JIRA.12640623.1469528173000@Atlassian.JIRA>
References: <JIRA.12640623.1469528173000@Atlassian.JIRA>
	<JIRA.12640623.1469528173179@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640623.1469528173000.12458.1469528221252@Atlassian.JIRA>

Michael Musgrove created JBTM-2706:
--------------------------------------

             Summary: Verify that we can run on the IBM JVM with OpenJDK
                 Key: JBTM-2706
                 URL: https://issues.jboss.org/browse/JBTM-2706
             Project: JBoss Transaction Manager
          Issue Type: Sub-task
          Components: JTS
    Affects Versions: 5.3.3.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.later


We need to set up a CI job that runs the JTS tests using the OpenJDK orb



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 06:23:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 26 Jul 2016 06:23:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2706) Verify that we can run on
 the IBM JVM with OpenJDK
In-Reply-To: <JIRA.12640623.1469528173000@Atlassian.JIRA>
References: <JIRA.12640623.1469528173000@Atlassian.JIRA>
	<JIRA.12640623.1469528173000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640623.1469528173000.12519.1469528580567@Atlassian.JIRA>


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

Michael Musgrove closed JBTM-2706.
----------------------------------
    Resolution: Done


The job name is narayana-ibm-jvm and the tests are passing

> Verify that we can run on the IBM JVM with OpenJDK
> --------------------------------------------------
>
>                 Key: JBTM-2706
>                 URL: https://issues.jboss.org/browse/JBTM-2706
>             Project: JBoss Transaction Manager
>          Issue Type: Sub-task
>          Components: JTS
>    Affects Versions: 5.3.3.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.later
>
>
> We need to set up a CI job that runs the JTS tests using the OpenJDK orb



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 06:38:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 26 Jul 2016 06:38:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2707) Update README to reflect
 accurately which JDK versions we support
In-Reply-To: <JIRA.12640628.1469529470000@Atlassian.JIRA>
References: <JIRA.12640628.1469529470000@Atlassian.JIRA>
	<JIRA.12640628.1469529470278@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640628.1469529470000.12650.1469529480921@Atlassian.JIRA>

Michael Musgrove created JBTM-2707:
--------------------------------------

             Summary: Update README to reflect accurately which JDK versions we support
                 Key: JBTM-2707
                 URL: https://issues.jboss.org/browse/JBTM-2707
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Documentation
    Affects Versions: 5.3.3.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


We are using Java 1.8 features and the top level README needs to reflect tha.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 06:48:02 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 26 Jul 2016 06:48:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2707) Update README to reflect
 accurately which JDK versions we support
In-Reply-To: <JIRA.12640628.1469529470000@Atlassian.JIRA>
References: <JIRA.12640628.1469529470000@Atlassian.JIRA>
	<JIRA.12640628.1469529470000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640628.1469529470000.12829.1469530082777@Atlassian.JIRA>


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

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


The maven enforcer plugin enforces JDK version 1.8 and I have updated the README.md to reflect that.

> Update README to reflect accurately which JDK versions we support
> -----------------------------------------------------------------
>
>                 Key: JBTM-2707
>                 URL: https://issues.jboss.org/browse/JBTM-2707
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 5.3.3.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> We are using Java 1.8 features and the top level README needs to reflect tha.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jul 26 09:11:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 26 Jul 2016 09:11:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2693) jca-and-hibernate
	quickstart CI failure
In-Reply-To: <JIRA.12634137.1466613817000@Atlassian.JIRA>
References: <JIRA.12634137.1466613817000@Atlassian.JIRA>
	<JIRA.12634137.1466613817000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12634137.1466613817000.14168.1469538660762@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-2693:
----------------------------------
    Fix Version/s: 5.next


> jca-and-hibernate quickstart CI failure
> ---------------------------------------
>
>                 Key: JBTM-2693
>                 URL: https://issues.jboss.org/browse/JBTM-2693
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Demonstrator
>    Affects Versions: 5.3.3.Final
>            Reporter: Michael Musgrove
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> The quickstart fails with a hibernate constraint violation:
> CI output: http://172.17.130.4:8083/job/narayana-quickstarts-ipv6/28
> Output: 
> {quote}
> 2016-06-18 07:36:23,944 [main] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Unique index or primary key violation: "UK_6M4FUHXJ4CKIXI1VSB8OSII7R_INDEX_5 ON PUBLIC.CUSTOMER(NAME)"; SQL statement:
> insert into Customer (name, id) values (?, ?) [23505-171]
> 2016-06-18 07:36:23,947 [main] WARN  com.arjuna.ats.arjuna - ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< -180000000000000:22cf30fffe66b53b:d118:5764ebe6:2a, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 1b0a7baf >
> javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement
> 2016-06-18 07:36:23,944 [main] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Unique index or primary key violation: "UK_6M4FUHXJ4CKIXI1VSB8OSII7R_INDEX_5 ON PUBLIC.CUSTOMER(NAME)"; SQL statement:
> insert into Customer (name, id) values (?, ?) [23505-171]
> 2016-06-18 07:36:23,947 [main] WARN  com.arjuna.ats.arjuna - ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< -180000000000000:22cf30fffe66b53b:d118:5764ebe6:2a, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 1b0a7baf >
> javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:17:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.18510.1469607420696@Atlassian.JIRA>


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

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


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Amos Feng
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:17:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.18518.1469607420997@Atlassian.JIRA>


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

Tom Jenkinson reassigned JBTM-2701:
-----------------------------------

    Assignee: Michael Musgrove  (was: Amos Feng)


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:18:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:18:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.18527.1469607480388@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2701:
--------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Unresolved


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:18:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:18:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.18533.1469607480747@Atlassian.JIRA>


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

Tom Jenkinson reopened JBTM-2701:
---------------------------------


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:30:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:30:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2708) Test does not close
	FileInputStream
In-Reply-To: <JIRA.12640794.1469608175000@Atlassian.JIRA>
References: <JIRA.12640794.1469608175000@Atlassian.JIRA>
	<JIRA.12640794.1469608175660@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640794.1469608175000.18773.1469608201392@Atlassian.JIRA>

Tom Jenkinson created JBTM-2708:
-----------------------------------

             Summary: Test does not close FileInputStream
                 Key: JBTM-2708
                 URL: https://issues.jboss.org/browse/JBTM-2708
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: Testing
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson
             Fix For: 5.next


{code}
public XARRTestResource(String xarrHelper, File file) throws IOException {
        this.xarrHelper = xarrHelper;
        this.file = file;
        DataInputStream fis = new DataInputStream(new FileInputStream(file));
        final int formatId = fis.readInt();
        final int gtrid_length = fis.readInt();
        final byte[] gtrid = new byte[gtrid_length];
        fis.read(gtrid, 0, gtrid_length);
        final int bqual_length = fis.readInt();
        final byte[] bqual = new byte[bqual_length];
        fis.read(bqual, 0, bqual_length);
        xids.put(file, new Xid() {

            @Override
            public byte[] getGlobalTransactionId() {
                return gtrid;
            }

            @Override
            public int getFormatId() {
                return formatId;
            }

            @Override
            public byte[] getBranchQualifier() {
                return bqual;
            }
        });
        fis.close();
    }
{code}

Spotted while working on JBTM-2614 backport



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:49:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295016@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.19124.1469609340844@Atlassian.JIRA>

Tom Jenkinson created JBTM-2709:
-----------------------------------

             Summary: ObjectStoreBrowser cannot cope with JDBC store on Windows
                 Key: JBTM-2709
                 URL: https://issues.jboss.org/browse/JBTM-2709
             Project: JBoss Transaction Manager
          Issue Type: Task
            Reporter: Tom Jenkinson


While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:49:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.19127.1469609340949@Atlassian.JIRA>


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

Tom Jenkinson reassigned JBTM-2709:
-----------------------------------

    Assignee: Michael Musgrove


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:49:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:49:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.19131.1469609341132@Atlassian.JIRA>


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

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


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:49:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 04:49:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.19135.1469609341269@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2709:
--------------------------------
    Issue Type: Bug  (was: Task)


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 04:56:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 27 Jul 2016 04:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.19212.1469609760701@Atlassian.JIRA>


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

RH Bugzilla Integration updated JBTM-2701:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1356589, https://bugzilla.redhat.com/show_bug.cgi?id=1360648
        Bugzilla Update: Perform


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 05:18:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 27 Jul 2016 05:18:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.19475.1469611080092@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2709:
--------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/jbosstm/narayana/pull/1035


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 06:23:01 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 27 Jul 2016 06:23:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.20096.1469614981757@Atlassian.JIRA>


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

RH Bugzilla Integration updated JBTM-2701:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1356589  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1356589, https://bugzilla.redhat.com/show_bug.cgi?id=1360648)


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Jul 27 06:24:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 27 Jul 2016 06:24:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned
 more frequently for prepared transactions
In-Reply-To: <JIRA.12638854.1468499306000@Atlassian.JIRA>
References: <JIRA.12638854.1468499306000@Atlassian.JIRA>
	<JIRA.12638854.1468499306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638854.1468499306000.20109.1469615040837@Atlassian.JIRA>


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

RH Bugzilla Integration updated JBTM-2701:
------------------------------------------
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=1356589)
        Bugzilla Update:   (was: Perform)


> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
>                 Key: JBTM-2701
>                 URL: https://issues.jboss.org/browse/JBTM-2701
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transaction Core
>    Affects Versions: 4.17.33
>         Environment: JBoss EA P6.4.8
>            Reporter: Tom Ross
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN  [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 04:35:02 2016
From: issues at jboss.org (Paul Robinson (JIRA))
Date: Thu, 28 Jul 2016 04:35:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1468) Support pure-JTA client
 and server for WS-AT and REST-AT
In-Reply-To: <JIRA.12484910.1360853576000@Atlassian.JIRA>
References: <JIRA.12484910.1360853576000@Atlassian.JIRA>
	<JIRA.12484910.1360853576000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484910.1360853576000.26815.1469694902186@Atlassian.JIRA>


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

Paul Robinson commented on JBTM-1468:
-------------------------------------

[~mmusgrov]: I think 1 is complete. IIRC, Web Service implementation classes (like: https://github.com/jbosstm/quickstart/blob/master/XTS/wsat-jta-multi_service/src/main/java/org/jboss/narayana/quickstarts/wsat/jtabridge/second/SecondServiceATImpl.java) needed to be marked in some way to allow the deployment processors in the AS to correctly set up the WSAT to JTA bridging. It looks like we now figure that out a different way, as the quickstart above is not using the annotation. 

> Support pure-JTA client and server for WS-AT and REST-AT
> --------------------------------------------------------
>
>                 Key: JBTM-1468
>                 URL: https://issues.jboss.org/browse/JBTM-1468
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: REST, XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 6.later
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT.
> To do this we need to:
> # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations.
> # Client side JTA->REST-AT bridge. Needs implementing.
> # Server side REST-AT->JTA bridge. Needs integrating into code base.
> # Update the TXBridge quickstarts to use this and move them out.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 04:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 04:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.27097.1469696160216@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2704:
-------------------------------------

You should document the requirement to deploy on a weld container. Just add a new section in the project docs with this note. Further docs can be added later.

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 05:48:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 05:48:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.27730.1469699280466@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-2704:
----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 05:49:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 05:49:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.27742.1469699341840@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2704:
-------------------------------------

You need to link a WFLY issue for the required WildFly changes. I don't think you should mark it resolved until the WFLY is resolved as that is the blocker.

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 06:53:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 06:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.28182.1469703180406@Atlassian.JIRA>


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

Gytis Trikleris commented on JBTM-2704:
---------------------------------------

So should I move it back to open even though the PR was merged?

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 07:00:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 07:00:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2680) Document compensations API
In-Reply-To: <JIRA.12627902.1464176492000@Atlassian.JIRA>
References: <JIRA.12627902.1464176492000@Atlassian.JIRA>
	<JIRA.12627902.1464176492000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627902.1464176492000.28223.1469703600211@Atlassian.JIRA>


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

Gytis Trikleris updated JBTM-2680:
----------------------------------
    Component/s: Documentation


> Document compensations API
> --------------------------
>
>                 Key: JBTM-2680
>                 URL: https://issues.jboss.org/browse/JBTM-2680
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Compensations, Documentation
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>
> There is no documentation for compensations API in our docs. Most of the things are covered in the quickstarts and blog, but adding something to the docs would be good too.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 07:02:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 07:02:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-987) Document Compensations API
In-Reply-To: <JIRA.12453232.1322502924000@Atlassian.JIRA>
References: <JIRA.12453232.1322502924000@Atlassian.JIRA>
	<JIRA.12453232.1322502924000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453232.1322502924000.28254.1469703720320@Atlassian.JIRA>


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

Gytis Trikleris closed JBTM-987.
--------------------------------
    Fix Version/s:     (was: 5.later)
         Assignee:     (was: Paul Robinson)
       Resolution: Duplicate Issue


> Document Compensations API
> --------------------------
>
>                 Key: JBTM-987
>                 URL: https://issues.jboss.org/browse/JBTM-987
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Compensations, Documentation
>            Reporter: Tom Jenkinson
>            Priority: Optional
>              Labels: TXFramework
>
> Should cover all existing features and provide a skeleton for the final document.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 07:05:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 07:05:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2678) @TxLogged annotation does
	not work
In-Reply-To: <JIRA.12627714.1464098858000@Atlassian.JIRA>
References: <JIRA.12627714.1464098858000@Atlassian.JIRA>
	<JIRA.12627714.1464098858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627714.1464098858000.28266.1469703900160@Atlassian.JIRA>


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

Gytis Trikleris commented on JBTM-2678:
---------------------------------------

Maybe we should remove @TxLogged annotation from the API then?

> @TxLogged annotation does not work
> ----------------------------------
>
>                 Key: JBTM-2678
>                 URL: https://issues.jboss.org/browse/JBTM-2678
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa58158c5e3ac6a#diff-a01554d0172e1da7703c5134820edb6aL124



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 07:23:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 28 Jul 2016 07:23:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter
 should be thread safe
In-Reply-To: <JIRA.12601243.1453811096000@Atlassian.JIRA>
References: <JIRA.12601243.1453811096000@Atlassian.JIRA>
	<JIRA.12601243.1453811096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601243.1453811096000.28415.1469704980633@Atlassian.JIRA>


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

RH Bugzilla Integration commented on JBTM-2614:
-----------------------------------------------

Miroslav Sochurek <msochure at redhat.com> changed the Status of [bug 1360648|https://bugzilla.redhat.com/show_bug.cgi?id=1360648] from NEW to ASSIGNED

> JCA TransactionImporter should be thread safe
> ---------------------------------------------
>
>                 Key: JBTM-2614
>                 URL: https://issues.jboss.org/browse/JBTM-2614
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 5.2.12.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.2.13.Final
>
>
> I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int).
> If two threads call this method at the same time, two separate transaction objects may be created.  Here's the sequence of events:
> T1: call importTransaction for XID1
> T2: call importTransaction for XID1
> T1: getImportedTransaction returns null
> T2: getImportedTransaction returns null
> T1: create new transaction, add to map
> T2: create new transaction, add to map (overwriting T1's)
> There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 07:28:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 07:28:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.28475.1469705281919@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2704:
-------------------------------------

No, just link to the docs is fine. But you should work on adding the docs for this before moving onto something else. And when I say, the "this" - I mean the particular issue we are discussing now. You just need to add the chapter for compensations into the docs, put "This is not complete" reference the docs issue JBTM-2680 and then add the note specific to this thing. Next time I will mention to add the docs PR before marking as ready to merge

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 07:29:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 07:29:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2678) @TxLogged annotation does
	not work
In-Reply-To: <JIRA.12627714.1464098858000@Atlassian.JIRA>
References: <JIRA.12627714.1464098858000@Atlassian.JIRA>
	<JIRA.12627714.1464098858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627714.1464098858000.28480.1469705340588@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2678:
-------------------------------------

[~paul.robinson] - can you describe the failure window. It sounds worrying.

[~gytis] - seems a candidate for deprecation but awaiting further feedback from Paul

> @TxLogged annotation does not work
> ----------------------------------
>
>                 Key: JBTM-2678
>                 URL: https://issues.jboss.org/browse/JBTM-2678
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa58158c5e3ac6a#diff-a01554d0172e1da7703c5134820edb6aL124



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 08:26:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 08:26:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.28872.1469708760176@Atlassian.JIRA>


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

Gytis Trikleris commented on JBTM-2704:
---------------------------------------

I mean should I move to open so that it could be resolved once WFLY issue is resolved?
But there isn't any documentation on this at the moment. Wouldn't the docs section look weird only with one note? 
I've also linked a docs JIRA as a follow up.

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 08:59:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 08:59:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.29063.1469710740156@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2704:
-------------------------------------

I don't think it will be weird, the doc has to start somewhere.

Regarding the other matter, we have to decide if the issue is resolved until all parts are merged. I don't think it can be considered resolved quite yet due to the outstanding WFLY requirement

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 09:03:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 28 Jul 2016 09:03:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework
 cannot instantiate bean from ear archive
In-Reply-To: <JIRA.12640451.1469437010000@Atlassian.JIRA>
References: <JIRA.12640451.1469437010000@Atlassian.JIRA>
	<JIRA.12640451.1469437010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640451.1469437010000.29105.1469710980495@Atlassian.JIRA>


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

Gytis Trikleris reopened JBTM-2704:
-----------------------------------


Reopening until WFLY-6890 blocker is merged.

> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
>                 Key: JBTM-2704
>                 URL: https://issues.jboss.org/browse/JBTM-2704
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Compensations
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 11:06:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 11:06:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2710) XATerminator.rollback
 does not invoke XAResource.rollback for failed resources when JTS is used
In-Reply-To: <JIRA.12641103.1469718294000@Atlassian.JIRA>
References: <JIRA.12641103.1469718294000@Atlassian.JIRA>
	<JIRA.12641103.1469718294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641103.1469718294000.30301.1469718360370@Atlassian.JIRA>


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

Tom Jenkinson moved JBEAP-5454 to JBTM-2710:
--------------------------------------------

              Project: JBoss Transaction Manager  (was: JBoss Enterprise Application Platform)
                  Key: JBTM-2710  (was: JBEAP-5454)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                       JTS
                           (was: Transactions)
    Affects Version/s:     (was: 7.0.0.GA)


> XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2710
>                 URL: https://issues.jboss.org/browse/JBTM-2710
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA, JTS
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>
> I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back.
> The scenario is following:
> There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction.
> # RAR is deployed
> # RAR opens a java socket where listens for message
> # MDB of TestResourceMessageListener is deployed
> # test client sends prepare command
> # test client sends commit command
> # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL
> # test client receives error code XAER_RMFAIL
> # test client sends recover command
> # test client receives number of in-doubt xid - which is one
> # test client sends rollback command
> # XATerminator calls rollback on the in-doubt xid
> # expecting TestXAResource.rollback would be called
> After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction  it runs fine).
> [1]
> {code}
> 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 )
> 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 11:49:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 11:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2710) XATerminator.rollback
 does not invoke XAResource.rollback for failed resources when JTS is used
In-Reply-To: <JIRA.12641103.1469718294000@Atlassian.JIRA>
References: <JIRA.12641103.1469718294000@Atlassian.JIRA>
	<JIRA.12641103.1469718294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641103.1469718294000.30846.1469720940294@Atlassian.JIRA>


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

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


> XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2710
>                 URL: https://issues.jboss.org/browse/JBTM-2710
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA, JTS
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>
> I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back.
> The scenario is following:
> There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction.
> # RAR is deployed
> # RAR opens a java socket where listens for message
> # MDB of TestResourceMessageListener is deployed
> # test client sends prepare command
> # test client sends commit command
> # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL
> # test client receives error code XAER_RMFAIL
> # test client sends recover command
> # test client receives number of in-doubt xid - which is one
> # test client sends rollback command
> # XATerminator calls rollback on the in-doubt xid
> # expecting TestXAResource.rollback would be called
> After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction  it runs fine).
> [1]
> {code}
> 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 )
> 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Jul 28 11:51:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 28 Jul 2016 11:51:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2710) XATerminator.rollback
 does not invoke XAResource.rollback for failed resources when JTS is used
In-Reply-To: <JIRA.12641103.1469718294000@Atlassian.JIRA>
References: <JIRA.12641103.1469718294000@Atlassian.JIRA>
	<JIRA.12641103.1469718294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641103.1469718294000.30863.1469721060190@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2710:
-------------------------------------

The issue is that the "massage" in ServerTransaction of the value does not take into account a failure during a prepared resource. During investigation there is also the possibility to leave the corba endpoint open if we get a transient retryable error in the JTA commit.

> XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2710
>                 URL: https://issues.jboss.org/browse/JBTM-2710
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA, JTS
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>
> I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back.
> The scenario is following:
> There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction.
> # RAR is deployed
> # RAR opens a java socket where listens for message
> # MDB of TestResourceMessageListener is deployed
> # test client sends prepare command
> # test client sends commit command
> # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL
> # test client receives error code XAER_RMFAIL
> # test client sends recover command
> # test client receives number of in-doubt xid - which is one
> # test client sends rollback command
> # XATerminator calls rollback on the in-doubt xid
> # expecting TestXAResource.rollback would be called
> After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction  it runs fine).
> [1]
> {code}
> 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 )
> 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 05:24:02 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 29 Jul 2016 05:24:02 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter
 should be thread safe
In-Reply-To: <JIRA.12601243.1453811096000@Atlassian.JIRA>
References: <JIRA.12601243.1453811096000@Atlassian.JIRA>
	<JIRA.12601243.1453811096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601243.1453811096000.35431.1469784242230@Atlassian.JIRA>


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

RH Bugzilla Integration commented on JBTM-2614:
-----------------------------------------------

Tom Ross <tom.ross at redhat.com> changed the Status of [bug 1360648|https://bugzilla.redhat.com/show_bug.cgi?id=1360648] from ASSIGNED to POST

> JCA TransactionImporter should be thread safe
> ---------------------------------------------
>
>                 Key: JBTM-2614
>                 URL: https://issues.jboss.org/browse/JBTM-2614
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 5.2.12.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.2.13.Final
>
>
> I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int).
> If two threads call this method at the same time, two separate transaction objects may be created.  Here's the sequence of events:
> T1: call importTransaction for XID1
> T2: call importTransaction for XID1
> T1: getImportedTransaction returns null
> T2: getImportedTransaction returns null
> T1: create new transaction, add to map
> T2: create new transaction, add to map (overwriting T1's)
> There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 06:41:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 06:41:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2711) Upgrade BlackTie to
 reference WildFly 11.0.0.Alpha1-SNAPSHOT
In-Reply-To: <JIRA.12641221.1469788831000@Atlassian.JIRA>
References: <JIRA.12641221.1469788831000@Atlassian.JIRA>
	<JIRA.12641221.1469788831345@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641221.1469788831000.36131.1469788860165@Atlassian.JIRA>

Tom Jenkinson created JBTM-2711:
-----------------------------------

             Summary: Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT
                 Key: JBTM-2711
                 URL: https://issues.jboss.org/browse/JBTM-2711
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: BlackTie
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson
            Priority: Blocker
             Fix For: 5.next


WildFly have gone to 11.0.0.Alpha1-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 06:44:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 06:44:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2711) Upgrade BlackTie to
 reference WildFly 11.0.0.Alpha1-SNAPSHOT
In-Reply-To: <JIRA.12641221.1469788831000@Atlassian.JIRA>
References: <JIRA.12641221.1469788831000@Atlassian.JIRA>
	<JIRA.12641221.1469788831000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641221.1469788831000.36178.1469789040834@Atlassian.JIRA>


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

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


> Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT
> ------------------------------------------------------------
>
>                 Key: JBTM-2711
>                 URL: https://issues.jboss.org/browse/JBTM-2711
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>             Fix For: 5.next
>
>
> WildFly have gone to 11.0.0.Alpha1-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 06:48:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 06:48:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing
In-Reply-To: <JIRA.12641223.1469789268000@Atlassian.JIRA>
References: <JIRA.12641223.1469789268000@Atlassian.JIRA>
	<JIRA.12641223.1469789268767@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641223.1469789268000.36216.1469789280885@Atlassian.JIRA>

Tom Jenkinson created JBTM-2712:
-----------------------------------

             Summary: Karaf build failing
                 Key: JBTM-2712
                 URL: https://issues.jboss.org/browse/JBTM-2712
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: OSGi
            Reporter: Tom Jenkinson
            Assignee: Amos Feng
            Priority: Blocker


The build of Karaf has started failing.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 06:49:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 06:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing
In-Reply-To: <JIRA.12641223.1469789269000@Atlassian.JIRA>
References: <JIRA.12641223.1469789269000@Atlassian.JIRA>
	<JIRA.12641223.1469789269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641223.1469789269000.36218.1469789340203@Atlassian.JIRA>


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

Tom Jenkinson commented on JBTM-2712:
-------------------------------------

http://albany.eng.hst.ams2.redhat.com/job/narayana-quickstarts/370/
http://albany.eng.hst.ams2.redhat.com/job/narayana-quickstarts-catelyn/964/

> Karaf build failing
> -------------------
>
>                 Key: JBTM-2712
>                 URL: https://issues.jboss.org/browse/JBTM-2712
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: OSGi
>            Reporter: Tom Jenkinson
>            Assignee: Amos Feng
>            Priority: Blocker
>
> The build of Karaf has started failing.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 09:49:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 09:49:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2713) Remove FileLock cruft
	from LogStore file
In-Reply-To: <JIRA.12641270.1469800103000@Atlassian.JIRA>
References: <JIRA.12641270.1469800103000@Atlassian.JIRA>
	<JIRA.12641270.1469800103860@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641270.1469800103000.38739.1469800140235@Atlassian.JIRA>

Tom Jenkinson created JBTM-2713:
-----------------------------------

             Summary: Remove FileLock cruft from LogStore file
                 Key: JBTM-2713
                 URL: https://issues.jboss.org/browse/JBTM-2713
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: Transaction Core
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson
            Priority: Minor
             Fix For: 5.next


It certainly isn't referenced:
https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce12e784fb6/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java#L734



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:53:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2708) Test does not close
	FileInputStream
In-Reply-To: <JIRA.12640794.1469608176000@Atlassian.JIRA>
References: <JIRA.12640794.1469608176000@Atlassian.JIRA>
	<JIRA.12640794.1469608176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640794.1469608176000.39094.1469803980346@Atlassian.JIRA>


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

Tom Jenkinson resolved JBTM-2708.
---------------------------------
    Resolution: Done


> Test does not close FileInputStream
> -----------------------------------
>
>                 Key: JBTM-2708
>                 URL: https://issues.jboss.org/browse/JBTM-2708
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Testing
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next
>
>
> {code}
> public XARRTestResource(String xarrHelper, File file) throws IOException {
>         this.xarrHelper = xarrHelper;
>         this.file = file;
>         DataInputStream fis = new DataInputStream(new FileInputStream(file));
>         final int formatId = fis.readInt();
>         final int gtrid_length = fis.readInt();
>         final byte[] gtrid = new byte[gtrid_length];
>         fis.read(gtrid, 0, gtrid_length);
>         final int bqual_length = fis.readInt();
>         final byte[] bqual = new byte[bqual_length];
>         fis.read(bqual, 0, bqual_length);
>         xids.put(file, new Xid() {
>             @Override
>             public byte[] getGlobalTransactionId() {
>                 return gtrid;
>             }
>             @Override
>             public int getFormatId() {
>                 return formatId;
>             }
>             @Override
>             public byte[] getBranchQualifier() {
>                 return bqual;
>             }
>         });
>         fis.close();
>     }
> {code}
> Spotted while working on JBTM-2614 backport



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:53:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:53:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.39095.1469803980368@Atlassian.JIRA>


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

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


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:54:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:54:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter
 should be thread safe
In-Reply-To: <JIRA.12601243.1453811096000@Atlassian.JIRA>
References: <JIRA.12601243.1453811096000@Atlassian.JIRA>
	<JIRA.12601243.1453811096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601243.1453811096000.39098.1469804040360@Atlassian.JIRA>


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

Tom Jenkinson reopened JBTM-2614:
---------------------------------


> JCA TransactionImporter should be thread safe
> ---------------------------------------------
>
>                 Key: JBTM-2614
>                 URL: https://issues.jboss.org/browse/JBTM-2614
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 5.2.12.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.2.13.Final
>
>
> I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int).
> If two threads call this method at the same time, two separate transaction objects may be created.  Here's the sequence of events:
> T1: call importTransaction for XID1
> T2: call importTransaction for XID1
> T1: getImportedTransaction returns null
> T2: getImportedTransaction returns null
> T1: create new transaction, add to map
> T2: create new transaction, add to map (overwriting T1's)
> There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:54:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:54:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter
 should be thread safe
In-Reply-To: <JIRA.12601243.1453811096000@Atlassian.JIRA>
References: <JIRA.12601243.1453811096000@Atlassian.JIRA>
	<JIRA.12601243.1453811096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601243.1453811096000.39101.1469804040428@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2614:
--------------------------------
    Fix Version/s: 4.17.35


> JCA TransactionImporter should be thread safe
> ---------------------------------------------
>
>                 Key: JBTM-2614
>                 URL: https://issues.jboss.org/browse/JBTM-2614
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 5.2.12.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 5.2.13.Final, 4.17.35
>
>
> I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int).
> If two threads call this method at the same time, two separate transaction objects may be created.  Here's the sequence of events:
> T1: call importTransaction for XID1
> T2: call importTransaction for XID1
> T1: getImportedTransaction returns null
> T2: getImportedTransaction returns null
> T1: create new transaction, add to map
> T2: create new transaction, add to map (overwriting T1's)
> There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:54:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:54:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter
 should be thread safe
In-Reply-To: <JIRA.12601243.1453811096000@Atlassian.JIRA>
References: <JIRA.12601243.1453811096000@Atlassian.JIRA>
	<JIRA.12601243.1453811096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601243.1453811096000.39104.1469804040543@Atlassian.JIRA>


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

Tom Jenkinson resolved JBTM-2614.
---------------------------------
    Resolution: Done


> JCA TransactionImporter should be thread safe
> ---------------------------------------------
>
>                 Key: JBTM-2614
>                 URL: https://issues.jboss.org/browse/JBTM-2614
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 5.2.12.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 4.17.35, 5.2.13.Final
>
>
> I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int).
> If two threads call this method at the same time, two separate transaction objects may be created.  Here's the sequence of events:
> T1: call importTransaction for XID1
> T2: call importTransaction for XID1
> T1: getImportedTransaction returns null
> T2: getImportedTransaction returns null
> T1: create new transaction, add to map
> T2: create new transaction, add to map (overwriting T1's)
> There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:54:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:54:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2708) Test does not close
	FileInputStream
In-Reply-To: <JIRA.12640794.1469608176000@Atlassian.JIRA>
References: <JIRA.12640794.1469608176000@Atlassian.JIRA>
	<JIRA.12640794.1469608176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640794.1469608176000.39107.1469804040613@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2708:
--------------------------------
    Fix Version/s: 4.17.35


> Test does not close FileInputStream
> -----------------------------------
>
>                 Key: JBTM-2708
>                 URL: https://issues.jboss.org/browse/JBTM-2708
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Testing
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next, 4.17.35
>
>
> {code}
> public XARRTestResource(String xarrHelper, File file) throws IOException {
>         this.xarrHelper = xarrHelper;
>         this.file = file;
>         DataInputStream fis = new DataInputStream(new FileInputStream(file));
>         final int formatId = fis.readInt();
>         final int gtrid_length = fis.readInt();
>         final byte[] gtrid = new byte[gtrid_length];
>         fis.read(gtrid, 0, gtrid_length);
>         final int bqual_length = fis.readInt();
>         final byte[] bqual = new byte[bqual_length];
>         fis.read(bqual, 0, bqual_length);
>         xids.put(file, new Xid() {
>             @Override
>             public byte[] getGlobalTransactionId() {
>                 return gtrid;
>             }
>             @Override
>             public int getFormatId() {
>                 return formatId;
>             }
>             @Override
>             public byte[] getBranchQualifier() {
>                 return bqual;
>             }
>         });
>         fis.close();
>     }
> {code}
> Spotted while working on JBTM-2614 backport



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:55:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:55:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.39109.1469804100065@Atlassian.JIRA>


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

Tom Jenkinson updated JBTM-2709:
--------------------------------
    Fix Version/s: 4.17.35


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next, 4.17.35
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.39111.1469804160276@Atlassian.JIRA>


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

Tom Jenkinson reopened JBTM-2709:
---------------------------------


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next, 4.17.35
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot
 cope with JDBC store on Windows
In-Reply-To: <JIRA.12640798.1469609295000@Atlassian.JIRA>
References: <JIRA.12640798.1469609295000@Atlassian.JIRA>
	<JIRA.12640798.1469609295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640798.1469609295000.39112.1469804160294@Atlassian.JIRA>


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

Tom Jenkinson resolved JBTM-2709.
---------------------------------
    Resolution: Done


> ObjectStoreBrowser cannot cope with JDBC store on Windows
> ---------------------------------------------------------
>
>                 Key: JBTM-2709
>                 URL: https://issues.jboss.org/browse/JBTM-2709
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 5.next, 4.17.35
>
>
> While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is
 committed at the same instance as a resource adapter/remote EJB calls
 XAT::recover() then you can get an NPE
In-Reply-To: <JIRA.12640258.1469180491000@Atlassian.JIRA>
References: <JIRA.12640258.1469180491000@Atlassian.JIRA>
	<JIRA.12640258.1469180491000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640258.1469180491000.39119.1469804160810@Atlassian.JIRA>


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

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


> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2703
>                 URL: https://issues.jboss.org/browse/JBTM-2703
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 5.next
>
>
> {code}
> INFO  [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] 	at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] 	at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] 	... 10 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Jul 29 10:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 29 Jul 2016 10:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2711) Upgrade BlackTie to
 reference WildFly 11.0.0.Alpha1-SNAPSHOT
In-Reply-To: <JIRA.12641221.1469788831000@Atlassian.JIRA>
References: <JIRA.12641221.1469788831000@Atlassian.JIRA>
	<JIRA.12641221.1469788831000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641221.1469788831000.39121.1469804160914@Atlassian.JIRA>


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

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


> Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT
> ------------------------------------------------------------
>
>                 Key: JBTM-2711
>                 URL: https://issues.jboss.org/browse/JBTM-2711
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: BlackTie
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>             Fix For: 5.next
>
>
> WildFly have gone to 11.0.0.Alpha1-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)