From issues at jboss.org Thu Dec 1 03:13:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 1 Dec 2016 03:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2805) Karaf fails to build in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13331986#comment-13331986 ] Amos Feng commented on JBTM-2805: --------------------------------- It needs maven >= 3.3 > Karaf fails to build in CI > -------------------------- > > Key: JBTM-2805 > URL: https://issues.jboss.org/browse/JBTM-2805 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Amos Feng > > We should try to avoid building Karaf in CI. > At this point it fails to build. > {code} > [INFO] --- maven-resources-plugin:2.7:resources (process-resources) @ apache-karaf-minimal --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 4 resources > [INFO] > [INFO] --- karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) @ apache-karaf-minimal --- > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Apache Karaf ....................................... SUCCESS [ 4.795 s] > [INFO] Apache Karaf :: JAAS ............................... SUCCESS [ 0.017 s] > [INFO] Apache Karaf :: JAAS :: Boot ....................... SUCCESS [ 2.413 s] > [INFO] Apache Karaf :: Util ............................... SUCCESS [ 4.843 s] > [INFO] Apache Karaf :: Main ............................... SUCCESS [ 11.143 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Features :: Extension .............. SUCCESS [ 0.157 s] > [INFO] Apache Karaf :: Service ............................ SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Service :: Guard ................... SUCCESS [ 8.831 s] > [INFO] Apache Karaf :: Shell .............................. SUCCESS [ 0.010 s] > [INFO] Apache Karaf :: Shell :: Core ...................... SUCCESS [ 6.523 s] > [INFO] Apache Karaf :: Tooling ............................ SUCCESS [ 0.013 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin for Services Metadata SUCCESS [ 58.898 s] > [INFO] Apache Karaf :: Features :: Core ................... SUCCESS [ 5.522 s] > [INFO] Apache Karaf :: Features :: Command ................ SUCCESS [ 0.845 s] > [INFO] Apache Karaf :: KAR :: Core ........................ SUCCESS [ 0.869 s] > [INFO] Apache Karaf :: JAAS :: Config ..................... SUCCESS [ 7.906 s] > [INFO] Apache Karaf :: JAAS :: Modules .................... SUCCESS [ 18.313 s] > [INFO] Apache Karaf :: Bundle ............................. SUCCESS [ 0.009 s] > [INFO] Apache Karaf :: Bundle :: Core ..................... SUCCESS [ 1.076 s] > [INFO] Apache Karaf :: Bundle :: BlueprintStateService .... SUCCESS [ 0.095 s] > [INFO] Apache Karaf :: Bundle :: SpringStateService ....... SUCCESS [ 8.690 s] > [INFO] Apache Karaf :: ConfigAdmin :: Core ................ SUCCESS [ 0.454 s] > [INFO] Apache Karaf :: Tooling :: Utils ................... SUCCESS [ 2.911 s] > [INFO] Apache Karaf :: Deployer ........................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Deployer :: Blueprint .............. SUCCESS [ 2.328 s] > [INFO] Apache Karaf :: Deployer :: Spring ................. SUCCESS [ 0.166 s] > [INFO] Apache Karaf :: Demos :: Profiles :: Registry ...... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Profile :: Core .................... SUCCESS [ 9.123 s] > [INFO] Apache Karaf :: Instance :: Core ................... SUCCESS [ 1.096 s] > [INFO] Apache Karaf :: Package :: Core .................... SUCCESS [ 0.316 s] > [INFO] Apache Karaf :: HTTP :: Core ....................... SUCCESS [ 3.623 s] > [INFO] Apache Karaf :: Service :: Core .................... SUCCESS [ 0.323 s] > [INFO] Apache Karaf :: Log :: Core ........................ SUCCESS [ 4.122 s] > [INFO] Apache Karaf :: Deployer :: Features ............... SUCCESS [ 0.568 s] > [INFO] Apache Karaf :: Deployer :: Karaf Archive (.kar) ... SUCCESS [ 0.491 s] > [INFO] Apache Karaf :: Deployer :: Wrap Non OSGi Jar ...... SUCCESS [ 0.100 s] > [INFO] Apache Karaf :: Shell :: Various Commands .......... SUCCESS [ 0.471 s] > [INFO] Apache Karaf :: Shell :: Console ................... SUCCESS [ 3.362 s] > [INFO] Apache Karaf :: Shell :: Table ..................... SUCCESS [ 0.111 s] > [INFO] Apache Karaf :: Shell :: SSH ....................... SUCCESS [ 2.032 s] > [INFO] Apache Karaf :: JAAS :: Jasypt Encryption .......... SUCCESS [ 2.921 s] > [INFO] Apache Karaf :: JAAS :: Command .................... SUCCESS [ 0.492 s] > [INFO] Apache Karaf :: JAAS :: Blueprint .................. SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Config ........ SUCCESS [ 0.081 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Jasypt ........ SUCCESS [ 1.509 s] > [INFO] Apache Karaf :: Client ............................. SUCCESS [ 0.164 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.212 s] > [INFO] Apache Karaf :: System :: Core ..................... SUCCESS [ 0.329 s] > [INFO] Apache Karaf :: Web :: Core ........................ SUCCESS [ 0.328 s] > [INFO] Apache Karaf :: Wrapper :: Core .................... SUCCESS [ 0.667 s] > [INFO] Apache Karaf :: Web Console ........................ SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Web Console :: Console ............. SUCCESS [ 3.205 s] > [INFO] Apache Karaf :: Web Console :: Features Plugin ..... SUCCESS [ 0.559 s] > [INFO] Apache Karaf :: Web Console :: Gogo Plugin ......... SUCCESS [ 0.617 s] > [INFO] Apache Karaf :: Web Console :: HTTP Plugin ......... SUCCESS [ 0.567 s] > [INFO] Apache Karaf :: Web Console :: Instance Plugin ..... SUCCESS [ 0.224 s] > [INFO] Apache Karaf :: Exception .......................... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Scheduler :: Core .................. SUCCESS [ 3.628 s] > [INFO] Apache Karaf :: Declarative Services (DS) .......... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: SCR :: Shell Commands .............. SUCCESS [ 3.391 s] > [INFO] Apache Karaf :: SCR :: Management MBeans ........... SUCCESS [ 1.491 s] > [INFO] Apache Karaf :: SCR :: Bundle State ................ SUCCESS [ 0.176 s] > [INFO] Apache Karaf :: SCR :: Examples .................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: SCR :: Examples :: Basic Service ... SUCCESS [ 0.060 s] > [INFO] Apache Karaf :: SCR :: Examples :: Managed Services SUCCESS [ 0.076 s] > [INFO] Apache Karaf :: SCR :: Examples :: Component Factories SUCCESS [ 0.063 s] > [INFO] Apache Karaf :: Diagnostic ......................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Diagnostic :: Boot ................. SUCCESS [ 0.096 s] > [INFO] Apache Karaf :: Diagnostic :: Core ................. SUCCESS [ 0.748 s] > [INFO] Apache Karaf :: OBR :: Core ........................ SUCCESS [ 1.771 s] > [INFO] Apache Karaf :: JNDI :: Core ....................... SUCCESS [ 1.765 s] > [INFO] Apache Karaf :: JDBC :: Core ....................... SUCCESS [ 0.410 s] > [INFO] Apache Karaf :: JMS :: Core ........................ SUCCESS [ 6.591 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Parent ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Hibernate ................... SUCCESS [ 8.436 s] > [INFO] Apache Karaf :: OSGi Services :: Coordinator ....... SUCCESS [ 1.763 s] > [INFO] Apache Karaf :: OSGi Services :: EventAdmin ........ SUCCESS [ 1.511 s] > [INFO] Apache Karaf :: OSGi Services :: Static ConfigAdmin SUCCESS [ 0.087 s] > [INFO] Apache Karaf :: OSGi Services ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Subsystem :: Core .................. SUCCESS [ 5.008 s] > [INFO] Apache Karaf :: OSGi Services :: Event ............. SUCCESS [ 1.709 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin ...... SUCCESS [ 7.875 s] > [INFO] Apache Karaf :: Assemblies ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Assemblies :: Features ............. SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Base ..... SUCCESS [ 3.828 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Framework SUCCESS [ 2.555 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Static ... SUCCESS [ 1.836 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Standard . SUCCESS [01:12 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Spring ... SUCCESS [01:19 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Enterprise SUCCESS [ 42.574 s] > [INFO] Apache Karaf :: Assemblies :: Demos ................ SUCCESS [ 0.075 s] > [INFO] Apache Karaf :: Assemblies :: Minimal Distribution . FAILURE [ 0.097 s] > [INFO] Apache Karaf :: Assemblies :: Default Distribution . SKIPPED > [INFO] Apache Karaf :: Demos .............................. SKIPPED > [INFO] Apache Karaf :: Demos :: Web ....................... SKIPPED > [INFO] Apache Karaf :: Demos :: Branding :: Shell ......... SKIPPED > [INFO] Apache Karaf :: Demos :: Command :: Extend Console . SKIPPED > [INFO] Apache Karaf :: Demos :: Demo Dump provider ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer .................. SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Kar ........... SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Bundle ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Dynamic Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Static Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles .................. SKIPPED > [INFO] Apache Karaf :: Archetypes ......................... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Assembly Archetype ... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Command Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Feature Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Kar Archetype ........ SKIPPED > [INFO] Apache Karaf :: Archetypes :: Bundle Archetype ..... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Blueprint Archetype .. SKIPPED > [INFO] Apache Karaf :: Integration Tests .................. SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 07:17 min > [INFO] Finished at: 2016-11-29T00:19:34+00:00 > [INFO] Final Memory: 165M/1003M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project apache-karaf-minimal: Unable to parse configuration of mojo org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly for parameter pidsToExtract: Cannot assign configuration entry 'pidsToExtract' with value '!jmx.acl.*, > [ERROR] !org.apache.karaf.command.acl.*, > [ERROR] *' of type java.lang.String to property of type java.util.List > [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/PluginConfigurationException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :apache-karaf-minimal > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 03:24:01 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 1 Dec 2016 03:24:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2805) Karaf fails to build in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #182 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Karaf fails to build in CI > -------------------------- > > Key: JBTM-2805 > URL: https://issues.jboss.org/browse/JBTM-2805 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Amos Feng > > We should try to avoid building Karaf in CI. > At this point it fails to build. > {code} > [INFO] --- maven-resources-plugin:2.7:resources (process-resources) @ apache-karaf-minimal --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 4 resources > [INFO] > [INFO] --- karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) @ apache-karaf-minimal --- > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Apache Karaf ....................................... SUCCESS [ 4.795 s] > [INFO] Apache Karaf :: JAAS ............................... SUCCESS [ 0.017 s] > [INFO] Apache Karaf :: JAAS :: Boot ....................... SUCCESS [ 2.413 s] > [INFO] Apache Karaf :: Util ............................... SUCCESS [ 4.843 s] > [INFO] Apache Karaf :: Main ............................... SUCCESS [ 11.143 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Features :: Extension .............. SUCCESS [ 0.157 s] > [INFO] Apache Karaf :: Service ............................ SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Service :: Guard ................... SUCCESS [ 8.831 s] > [INFO] Apache Karaf :: Shell .............................. SUCCESS [ 0.010 s] > [INFO] Apache Karaf :: Shell :: Core ...................... SUCCESS [ 6.523 s] > [INFO] Apache Karaf :: Tooling ............................ SUCCESS [ 0.013 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin for Services Metadata SUCCESS [ 58.898 s] > [INFO] Apache Karaf :: Features :: Core ................... SUCCESS [ 5.522 s] > [INFO] Apache Karaf :: Features :: Command ................ SUCCESS [ 0.845 s] > [INFO] Apache Karaf :: KAR :: Core ........................ SUCCESS [ 0.869 s] > [INFO] Apache Karaf :: JAAS :: Config ..................... SUCCESS [ 7.906 s] > [INFO] Apache Karaf :: JAAS :: Modules .................... SUCCESS [ 18.313 s] > [INFO] Apache Karaf :: Bundle ............................. SUCCESS [ 0.009 s] > [INFO] Apache Karaf :: Bundle :: Core ..................... SUCCESS [ 1.076 s] > [INFO] Apache Karaf :: Bundle :: BlueprintStateService .... SUCCESS [ 0.095 s] > [INFO] Apache Karaf :: Bundle :: SpringStateService ....... SUCCESS [ 8.690 s] > [INFO] Apache Karaf :: ConfigAdmin :: Core ................ SUCCESS [ 0.454 s] > [INFO] Apache Karaf :: Tooling :: Utils ................... SUCCESS [ 2.911 s] > [INFO] Apache Karaf :: Deployer ........................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Deployer :: Blueprint .............. SUCCESS [ 2.328 s] > [INFO] Apache Karaf :: Deployer :: Spring ................. SUCCESS [ 0.166 s] > [INFO] Apache Karaf :: Demos :: Profiles :: Registry ...... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Profile :: Core .................... SUCCESS [ 9.123 s] > [INFO] Apache Karaf :: Instance :: Core ................... SUCCESS [ 1.096 s] > [INFO] Apache Karaf :: Package :: Core .................... SUCCESS [ 0.316 s] > [INFO] Apache Karaf :: HTTP :: Core ....................... SUCCESS [ 3.623 s] > [INFO] Apache Karaf :: Service :: Core .................... SUCCESS [ 0.323 s] > [INFO] Apache Karaf :: Log :: Core ........................ SUCCESS [ 4.122 s] > [INFO] Apache Karaf :: Deployer :: Features ............... SUCCESS [ 0.568 s] > [INFO] Apache Karaf :: Deployer :: Karaf Archive (.kar) ... SUCCESS [ 0.491 s] > [INFO] Apache Karaf :: Deployer :: Wrap Non OSGi Jar ...... SUCCESS [ 0.100 s] > [INFO] Apache Karaf :: Shell :: Various Commands .......... SUCCESS [ 0.471 s] > [INFO] Apache Karaf :: Shell :: Console ................... SUCCESS [ 3.362 s] > [INFO] Apache Karaf :: Shell :: Table ..................... SUCCESS [ 0.111 s] > [INFO] Apache Karaf :: Shell :: SSH ....................... SUCCESS [ 2.032 s] > [INFO] Apache Karaf :: JAAS :: Jasypt Encryption .......... SUCCESS [ 2.921 s] > [INFO] Apache Karaf :: JAAS :: Command .................... SUCCESS [ 0.492 s] > [INFO] Apache Karaf :: JAAS :: Blueprint .................. SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Config ........ SUCCESS [ 0.081 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Jasypt ........ SUCCESS [ 1.509 s] > [INFO] Apache Karaf :: Client ............................. SUCCESS [ 0.164 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.212 s] > [INFO] Apache Karaf :: System :: Core ..................... SUCCESS [ 0.329 s] > [INFO] Apache Karaf :: Web :: Core ........................ SUCCESS [ 0.328 s] > [INFO] Apache Karaf :: Wrapper :: Core .................... SUCCESS [ 0.667 s] > [INFO] Apache Karaf :: Web Console ........................ SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Web Console :: Console ............. SUCCESS [ 3.205 s] > [INFO] Apache Karaf :: Web Console :: Features Plugin ..... SUCCESS [ 0.559 s] > [INFO] Apache Karaf :: Web Console :: Gogo Plugin ......... SUCCESS [ 0.617 s] > [INFO] Apache Karaf :: Web Console :: HTTP Plugin ......... SUCCESS [ 0.567 s] > [INFO] Apache Karaf :: Web Console :: Instance Plugin ..... SUCCESS [ 0.224 s] > [INFO] Apache Karaf :: Exception .......................... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Scheduler :: Core .................. SUCCESS [ 3.628 s] > [INFO] Apache Karaf :: Declarative Services (DS) .......... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: SCR :: Shell Commands .............. SUCCESS [ 3.391 s] > [INFO] Apache Karaf :: SCR :: Management MBeans ........... SUCCESS [ 1.491 s] > [INFO] Apache Karaf :: SCR :: Bundle State ................ SUCCESS [ 0.176 s] > [INFO] Apache Karaf :: SCR :: Examples .................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: SCR :: Examples :: Basic Service ... SUCCESS [ 0.060 s] > [INFO] Apache Karaf :: SCR :: Examples :: Managed Services SUCCESS [ 0.076 s] > [INFO] Apache Karaf :: SCR :: Examples :: Component Factories SUCCESS [ 0.063 s] > [INFO] Apache Karaf :: Diagnostic ......................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Diagnostic :: Boot ................. SUCCESS [ 0.096 s] > [INFO] Apache Karaf :: Diagnostic :: Core ................. SUCCESS [ 0.748 s] > [INFO] Apache Karaf :: OBR :: Core ........................ SUCCESS [ 1.771 s] > [INFO] Apache Karaf :: JNDI :: Core ....................... SUCCESS [ 1.765 s] > [INFO] Apache Karaf :: JDBC :: Core ....................... SUCCESS [ 0.410 s] > [INFO] Apache Karaf :: JMS :: Core ........................ SUCCESS [ 6.591 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Parent ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Hibernate ................... SUCCESS [ 8.436 s] > [INFO] Apache Karaf :: OSGi Services :: Coordinator ....... SUCCESS [ 1.763 s] > [INFO] Apache Karaf :: OSGi Services :: EventAdmin ........ SUCCESS [ 1.511 s] > [INFO] Apache Karaf :: OSGi Services :: Static ConfigAdmin SUCCESS [ 0.087 s] > [INFO] Apache Karaf :: OSGi Services ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Subsystem :: Core .................. SUCCESS [ 5.008 s] > [INFO] Apache Karaf :: OSGi Services :: Event ............. SUCCESS [ 1.709 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin ...... SUCCESS [ 7.875 s] > [INFO] Apache Karaf :: Assemblies ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Assemblies :: Features ............. SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Base ..... SUCCESS [ 3.828 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Framework SUCCESS [ 2.555 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Static ... SUCCESS [ 1.836 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Standard . SUCCESS [01:12 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Spring ... SUCCESS [01:19 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Enterprise SUCCESS [ 42.574 s] > [INFO] Apache Karaf :: Assemblies :: Demos ................ SUCCESS [ 0.075 s] > [INFO] Apache Karaf :: Assemblies :: Minimal Distribution . FAILURE [ 0.097 s] > [INFO] Apache Karaf :: Assemblies :: Default Distribution . SKIPPED > [INFO] Apache Karaf :: Demos .............................. SKIPPED > [INFO] Apache Karaf :: Demos :: Web ....................... SKIPPED > [INFO] Apache Karaf :: Demos :: Branding :: Shell ......... SKIPPED > [INFO] Apache Karaf :: Demos :: Command :: Extend Console . SKIPPED > [INFO] Apache Karaf :: Demos :: Demo Dump provider ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer .................. SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Kar ........... SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Bundle ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Dynamic Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Static Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles .................. SKIPPED > [INFO] Apache Karaf :: Archetypes ......................... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Assembly Archetype ... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Command Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Feature Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Kar Archetype ........ SKIPPED > [INFO] Apache Karaf :: Archetypes :: Bundle Archetype ..... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Blueprint Archetype .. SKIPPED > [INFO] Apache Karaf :: Integration Tests .................. SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 07:17 min > [INFO] Finished at: 2016-11-29T00:19:34+00:00 > [INFO] Final Memory: 165M/1003M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project apache-karaf-minimal: Unable to parse configuration of mojo org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly for parameter pidsToExtract: Cannot assign configuration entry 'pidsToExtract' with value '!jmx.acl.*, > [ERROR] !org.apache.karaf.command.acl.*, > [ERROR] *' of type java.lang.String to property of type java.util.List > [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/PluginConfigurationException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :apache-karaf-minimal > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 04:53:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 1 Dec 2016 04:53:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2806) Javadoc JMS module In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2806: ------------------------------------- Summary: Javadoc JMS module Key: JBTM-2806 URL: https://issues.jboss.org/browse/JBTM-2806 Project: JBoss Transaction Manager Issue Type: Task Components: JTA Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 04:54:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 1 Dec 2016 04:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2806) Javadoc JMS module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2806 started by Gytis Trikleris. --------------------------------------------- > Javadoc JMS module > ------------------ > > Key: JBTM-2806 > URL: https://issues.jboss.org/browse/JBTM-2806 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 05:46:08 2016 From: issues at jboss.org (Ivan Straka (JIRA)) Date: Thu, 1 Dec 2016 05:46:08 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2807) StoreManager return always the same store In-Reply-To: References: Message-ID: Ivan Straka created JBTM-2807: --------------------------------- Summary: StoreManager return always the same store Key: JBTM-2807 URL: https://issues.jboss.org/browse/JBTM-2807 Project: JBoss Transaction Manager Issue Type: Bug Affects Versions: 5.4.0.Final Reporter: Ivan Straka Assignee: Ivan Straka StoreManager.get*Store() returns always the same store even after changing it via BeanPopulator. Problem is that StoreManager.actionStore, StoreManager.stateStore, StoreManager.communicationStore won't change after they are set for the first time. https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L53 this method should null stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 05:50:00 2016 From: issues at jboss.org (Anonymous (JIRA)) Date: Thu, 1 Dec 2016 05:50:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2807) StoreManager return always the same store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when istraka created pull request #1094 in GitHub -------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > StoreManager return always the same store > ----------------------------------------- > > Key: JBTM-2807 > URL: https://issues.jboss.org/browse/JBTM-2807 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ivan Straka > Assignee: Ivan Straka > > StoreManager.get*Store() returns always the same store even after changing it via BeanPopulator. > Problem is that StoreManager.actionStore, StoreManager.stateStore, StoreManager.communicationStore won't change after they are set for the first time. > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L53 > this method should null stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 05:51:03 2016 From: issues at jboss.org (Ivan Straka (JIRA)) Date: Thu, 1 Dec 2016 05:51:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2807) StoreManager return always the same store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Straka updated JBTM-2807: ------------------------------ Git Pull Request: https://github.com/jbosstm/narayana/pull/1094 > StoreManager return always the same store > ----------------------------------------- > > Key: JBTM-2807 > URL: https://issues.jboss.org/browse/JBTM-2807 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ivan Straka > Assignee: Ivan Straka > > StoreManager.get*Store() returns always the same store even after changing it via BeanPopulator. > Problem is that StoreManager.actionStore, StoreManager.stateStore, StoreManager.communicationStore won't change after they are set for the first time. > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L53 > this method should null stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 06:18:03 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 1 Dec 2016 06:18:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2654) Provide a method to restart the StoreManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2654. ---------------------------------- Resolution: Duplicate Duplicate of https://issues.jboss.org/browse/JBTM-2807 > Provide a method to restart the StoreManager > -------------------------------------------- > > Key: JBTM-2654 > URL: https://issues.jboss.org/browse/JBTM-2654 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > > In the tooling I would like to be able to dynamically change object stores but the various stores (actionStore, stateStore and communicationStore) are cached and the StoreManager.shutdown() method does not null these variables so they can never be reinitialised. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 06:37:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 1 Dec 2016 06:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2806) Javadoc JMS module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1095 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Javadoc JMS module > ------------------ > > Key: JBTM-2806 > URL: https://issues.jboss.org/browse/JBTM-2806 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 09:06:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 1 Dec 2016 09:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2798) Connection.isClosed throws NullPointerException or returns false after close In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2798: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Connection.isClosed throws NullPointerException or returns false after close > ---------------------------------------------------------------------------- > > Key: JBTM-2798 > URL: https://issues.jboss.org/browse/JBTM-2798 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Mirko Streckenbach > > The following snippet fails with a NullPointerException: > {code} > Connection c = ConnectionManager.create(dbUrl, properties); > System.err.println("closed1=" + c.isClosed()); > c.close(); > System.err.println("closed2=" + c.isClosed()); > {code} > output: > {code} > closed1=false > java.lang.NullPointerException > at com.arjuna.ats.internal.jdbc.ConnectionImple.closeImpl(ConnectionImple.java:389) > at com.arjuna.ats.internal.jdbc.ConnectionImple.close(ConnectionImple.java:381) > at org.jboss.narayana.quickstarts.jta.Main.main(Main.java:140) > {code} > If it is modified to "use" the init the physical connect before closing, it will not throw an > exception, but returns false for isClosed after the close: > {code} > Connection c = ConnectionManager.create(dbUrl, properties); > System.err.println("closed1=" + c.isClosed()); > c.createStatement().close(); > System.err.println("closed2=" + c.isClosed()); > c.close(); > System.err.println("closed3=" + c.isClosed()); > {code} > output: > {code} > closed1=false > closed2=false > closed3=false > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 1 12:07:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 1 Dec 2016 12:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2807) StoreManager return always the same store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2807: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > StoreManager return always the same store > ----------------------------------------- > > Key: JBTM-2807 > URL: https://issues.jboss.org/browse/JBTM-2807 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ivan Straka > Assignee: Ivan Straka > > StoreManager.get*Store() returns always the same store even after changing it via BeanPopulator. > Problem is that StoreManager.actionStore, StoreManager.stateStore, StoreManager.communicationStore won't change after they are set for the first time. > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L53 > this method should null stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 06:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 06:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2808: ----------------------------------- Summary: Hang in getThreadId Key: JBTM-2808 URL: https://issues.jboss.org/browse/JBTM-2808 Project: JBoss Transaction Manager Issue Type: Task Reporter: Tom Jenkinson at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) at java.util.WeakHashMap.getTable(WeakHashMap.java:350) at java.util.WeakHashMap.get(WeakHashMap.java:397) at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) No other locking, seems WeakHashMap needs synchronized. https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 06:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 06:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2808: ----------------------------------- Assignee: Tom Jenkinson > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 06:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 06:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2808: -------------------------------- Fix Version/s: 5.next > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 06:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 06:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2808: -------------------------------- Issue Type: Bug (was: Task) > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 06:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 06:30:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1096 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 08:37:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 08:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2809) Include jboss-logging in the QA dependencies so it can be debugged easier In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2809: ----------------------------------- Summary: Include jboss-logging in the QA dependencies so it can be debugged easier Key: JBTM-2809 URL: https://issues.jboss.org/browse/JBTM-2809 Project: JBoss Transaction Manager Issue Type: Task Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Unless jboss-logging is included you can't see tracing on the console when debugging issues -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 08:39:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 08:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2810) Add a test to show RMERR handling In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2810: ----------------------------------- Summary: Add a test to show RMERR handling Key: JBTM-2810 URL: https://issues.jboss.org/browse/JBTM-2810 Project: JBoss Transaction Manager Issue Type: Task Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next We had a question about why the log was now left when an XAR throws a HEURB. It was because if the forget fails we now remember the log. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 2 09:29:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 2 Dec 2016 09:29:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2791) JTS bottom-up could roll-back prepared inflowed JCA transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2791. ------------------------------- Resolution: Duplicate Issue Duplicate of JBTM-2767 > JTS bottom-up could roll-back prepared inflowed JCA transactions > ---------------------------------------------------------------- > > Key: JBTM-2791 > URL: https://issues.jboss.org/browse/JBTM-2791 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Attachments: 5.3.3.Final-fail-jvmCrashAfterPrepareJTS_jts_server.log, 5.3.5.Final-fail-jvmCrashAfterPrepareJTS_jts_server.log, 5.3.5.Final-pass-jvmCrashAfterPrepareJTS_jts_server.log > > > I experience race condition in my testcase for JBTM-2748/JBEAP-5880. Even by "detailed" investigation on {{server.log}} I'm a bit lost in what can cause the problem. By my testing I can see that Narayana 5.3.3.Final fails my test anytime. Narayana 5.3.5.Final seems to pass in most of the cases but time to time fails. The result is the same as at 5.3.3.Final. Nevertheless I can see different behavior shown by {{server.log}}. > For Narayana 5.3.3.Final during the JTS recovery second phase TM gets txn status and decides to rollback [1]. > For Narayana 5.3.5.Final during the JTS recovery second phase if TM gets txn status it goes for commit but if there is some trouble to get it it rollbacks. The problem that I refer to is represented by error {{WARN? [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022139: CORBA exception on trying to contact original process: org.omg.CORBA.BAD_OPERATION}} [2]. > I'm adding three server logs as attachment - fail for 5.3.3.Final and two for 5.3.5.Final - one failing, one passing. > [1] > {code} > 2016-11-16 15:16:52,985 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning 2 Xids > 2016-11-16 15:16:52,985 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning xid: < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:16:52,985 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning xid: < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:16:52,985 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 31a25bc7, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 3f537a39}, transactionOriginNodeIdentifier='1'} 1479305802928 1479305812985 false > 2016-11-16 15:16:52,987 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) 1479305802969 1479305812985 false > 2016-11-16 15:16:52,987 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 7a29e943 1479305802948 1479305812987 false > 2016-11-16 15:16:52,987 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > 2016-11-16 15:16:52,987 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change SECOND_PASS->IDLE > 2016-11-16 15:16:52,987 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:16:52,987 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE > 2016-11-16 15:16:52,987 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan thread signals listener worker > 2016-11-16 15:16:52,987 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off > 2016-11-16 15:17:12,988 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Connected to 127.0.0.1 on port 50586 on listener port 4712 for service com.arjuna.ats.internal.arjuna.recovery.WorkerService > 2016-11-16 15:17:12,989 DEBUG [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:50586) PeriodicRecovery: listener worker interrupts background thread > 2016-11-16 15:17:12,989 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING > 2016-11-16 15:17:12,989 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning > 2016-11-16 15:17:12,989 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery first pass at Wed, 16 Nov 2016 15:17:12 > 2016-11-16 15:17:12,989 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::periodicWorkFirstPass > 2016-11-16 15:17:12,989 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,989 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:12,989 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,990 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,990 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,990 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,990 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions > 2016-11-16 15:17:12,990 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:12,990 DEBUG [com.arjuna.ats.txoj] (Periodic Recovery) TORecoveryModule - first pass > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: ) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 28 > OutputObjectState Buffer: , StateManager) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 60 > OutputObjectState Buffer: , StateManager/BasicAction) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 112 > OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 184 > OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 276 > OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 372 > OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 396 > OutputObjectState Buffer: , RecoveryCoordinator) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 416 > OutputObjectState Buffer: , CosTransactions) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 456 > OutputObjectState Buffer: , CosTransactions/XAResourceRecord) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 472 > OutputObjectState Buffer: , Recovery) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffff7f000001:57fceedf:582c6a40:3c > OutputObjectState Type : null > OutputObjectState Size : 500 > OutputObjectState Buffer: , Recovery/FactoryContact) > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,990 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA, StateType.OS_SHADOW) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA, 10) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA, StateType.OS_ORIGINAL) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA, 11) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(RecoveryCoordinator, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff52e38d0c:c91:4140398c:0, RecoveryCoordinator, StateType.OS_SHADOW) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff52e38d0c:c91:4140398c:0, RecoveryCoordinator, 10) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff52e38d0c:c91:4140398c:0, RecoveryCoordinator, StateType.OS_ORIGINAL) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff52e38d0c:c91:4140398c:0, RecoveryCoordinator, 11) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff52e38d0c:c91:4140398c:0, RecoveryCoordinator) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(CosTransactions, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(CosTransactions/XAResourceRecord, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:12,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2e, CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2b, CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(Recovery, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(Recovery/FactoryContact, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , 2) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, Recovery/FactoryContact, StateType.OS_SHADOW) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, Recovery/FactoryContact, 10) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, Recovery/FactoryContact, 11) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:10, Recovery/FactoryContact) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:57fceedf:582c6a40:1b, Recovery/FactoryContact, StateType.OS_SHADOW) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:57fceedf:582c6a40:1b, Recovery/FactoryContact, 10) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:57fceedf:582c6a40:1b, Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:57fceedf:582c6a40:1b, Recovery/FactoryContact, 11) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:57fceedf:582c6a40:1b, Recovery/FactoryContact) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:12,992 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:12,992 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022199: TopLevelTransactionRecoveryModule First Pass > 2016-11-16 15:17:12,992 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022213: TransactionRecoveryModule.periodicWorkFirstPass() > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,992 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) TransactionRecoveryModule: scanning for /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,992 INFO [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:50586) ARJUNA012340: RecoveryManager scan scheduled to begin. > 2016-11-16 15:17:12,992 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:12,992 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022190: ServerTransactionRecoveryModule - First Pass > 2016-11-16 15:17:12,992 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022213: TransactionRecoveryModule.periodicWorkFirstPass() > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,992 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) TransactionRecoveryModule: scanning for /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:12,992 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,992 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:12,992 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change IDLE->FIRST_PASS > 2016-11-16 15:17:12,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule - first pass > 2016-11-16 15:17:12,993 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:12,993 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/CosTransactions/XAResourceRecord, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:12,993 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:12,995 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) getXAResources() instance: TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) > 2016-11-16 15:17:12,997 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery of RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 31a25bc7, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 3f537a39}, transactionOriginNodeIdentifier='1'} > 2016-11-16 15:17:12,997 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found 0 xids in doubt > 2016-11-16 15:17:12,997 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids updateIfEquivalentRM2 RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 31a25bc7, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 3f537a39}, transactionOriginNodeIdentifier='1'} 1479305832997 > 2016-11-16 15:17:12,997 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery of org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 7a29e943 > 2016-11-16 15:17:12,998 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found 0 xids in doubt > 2016-11-16 15:17:13,001 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery of TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) > 2016-11-16 15:17:13,005 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.recover(i=16777216)[id=512] > 2016-11-16 15:17:13,005 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) recover() > 2016-11-16 15:17:13,005 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning 2 Xids > 2016-11-16 15:17:13,005 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning xid: < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:13,005 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning xid: < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:13,005 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found 2 xids in doubt > 2016-11-16 15:17:13,005 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Recovered: < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:13,005 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Recovered: < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:13,010 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 31a25bc7, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 3f537a39}, transactionOriginNodeIdentifier='1'})[return 'false'][id=512] > 2016-11-16 15:17:13,013 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids updateIfEquivalentRM1 TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) 1479305833010 > 2016-11-16 15:17:13,016 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 7a29e943)[return 'false'][id=512] > 2016-11-16 15:17:13,017 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) getJndiName()[return java:/TestXAResource][id=512] > 2016-11-16 15:17:13,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change FIRST_PASS->BETWEEN_PASSES > 2016-11-16 15:17:13,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:23,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery second pass at Wed, 16 Nov 2016 15:17:23 > 2016-11-16 15:17:23,017 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() > 2016-11-16 15:17:23,017 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 0 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:23,017 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:23,017 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, InputObjectState Uid : 0:0:0:0:0 > InputObjectState Type : null > InputObjectState Size : 40 > InputObjectState Buffer: , -1) > 2016-11-16 15:17:23,017 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 15:17:23,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:23,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass > 2016-11-16 15:17:23,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:23,017 DEBUG [com.arjuna.ats.txoj] (Periodic Recovery) TORecoveryModule - second pass > 2016-11-16 15:17:23,017 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:23,018 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022200: TopLevelTransactionRecoveryModule Second Pass > 2016-11-16 15:17:23,018 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022214: TransactionRecoveryModule.periodicWorkSecondPass() > 2016-11-16 15:17:23,018 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:23,018 INFO [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022191: ServerTransactionRecoveryModule - Second Pass > 2016-11-16 15:17:23,018 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) > 2016-11-16 15:17:23,018 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2016-11-16 15:17:23,018 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule - second pass > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/CosTransactions/XAResourceRecord/0_ffff7f000001_5857c0a5_582c6a36_2e, FileLock.F_RDLCK, false) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) > 2016-11-16 15:17:23,018 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/CosTransactions/XAResourceRecord/0_ffff7f000001_5857c0a5_582c6a36_2e, java.io.FileInputStream at 655e320b, null) > 2016-11-16 15:17:23,019 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XARecovery 0:ffff7f000001:5857c0a5:582c6a36:2e is non-recoverable > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,019 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:23,020 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,020 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,020 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/CosTransactions/XAResourceRecord/0_ffff7f000001_5857c0a5_582c6a36_2b, FileLock.F_RDLCK, false) > 2016-11-16 15:17:23,020 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffff7f000001:5857c0a5:582c6a36:2b, /CosTransactions/XAResourceRecord) > 2016-11-16 15:17:23,020 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/CosTransactions/XAResourceRecord/0_ffff7f000001_5857c0a5_582c6a36_2b, java.io.FileInputStream at 4c2e5fd0, null) > 2016-11-16 15:17:23,021 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XARecovery 0:ffff7f000001:5857c0a5:582c6a36:2b is non-recoverable > 2016-11-16 15:17:23,021 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.transactionInitiatedRecovery completed > 2016-11-16 15:17:23,021 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery second pass of RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 31a25bc7, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 3f537a39}, transactionOriginNodeIdentifier='1'} > 2016-11-16 15:17:23,021 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 0 Xids to recover on this pass. > 2016-11-16 15:17:23,021 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery second pass of org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 7a29e943 > 2016-11-16 15:17:23,021 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 0 Xids to recover on this pass. > 2016-11-16 15:17:23,024 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery second pass of TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) > 2016-11-16 15:17:23,028 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover yes TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) 1479305802973 === 1479305843024 > 2016-11-16 15:17:23,030 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover no TestXAResourceRecovered(TestXAResourceCommon(id:512, xid:null, timeout:0, prepareReturn:0)) 1479305802973 === 1479305843024 > 2016-11-16 15:17:23,030 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass. > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_SHADOW) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 10) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord, 11) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/CosTransactions/XAResourceRecord/0_ffff7f000001_5857c0a5_582c6a36_2e, FileLock.F_RDLCK, false) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffff7f000001:5857c0a5:582c6a36:2e, /CosTransactions/XAResourceRecord) > 2016-11-16 15:17:23,031 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/CosTransactions/XAResourceRecord/0_ffff7f000001_5857c0a5_582c6a36_2e, java.io.FileInputStream at 75d2f77a, null) > 2016-11-16 15:17:23,032 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover > 2016-11-16 15:17:23,033 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::objectIsReady (Servant) > 2016-11-16 15:17:23,034 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::send_request ( _is_a ) nodeId=1 requestId=7 > 2016-11-16 15:17:23,035 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( _is_a ) nodeId=1 requestId=7 > 2016-11-16 15:17:23,035 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request ( _is_a ) nodeId=1 requestId=7 > 2016-11-16 15:17:23,035 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( _is_a ) nodeId=1 requestId=7 > 2016-11-16 15:17:23,035 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( _is_a ) nodeId=1 requestId=7 > 2016-11-16 15:17:23,036 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( _is_a ) nodeId=1 requestId=7 > 2016-11-16 15:17:23,039 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::send_request ( replay_completion ) nodeId=1 requestId=8 > 2016-11-16 15:17:23,039 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ContextManager::current () > 2016-11-16 15:17:23,040 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( replay_completion ) nodeId=1 requestId=8 > 2016-11-16 15:17:23,041 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request ( replay_completion ) nodeId=1 requestId=8 > 2016-11-16 15:17:23,041 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) JavaIdlRCDefaultServant::replay_completion) > 2016-11-16 15:17:23,042 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) RecoveryCoordinatorId(0:ffff7f000001:5857c0a5:582c6a36:2f*0:ffff7f000001:5857c0a5:582c6a36:25*0:ffff7f000001:5857c0a5:582c6a36:10*true) > 2016-11-16 15:17:23,042 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) JavaIdlDefaultServant replay_completion for Id (0:ffff7f000001:5857c0a5:582c6a36:2f, 0:ffff7f000001:5857c0a5:582c6a36:25, 0:ffff7f000001:5857c0a5:582c6a36:10, interposed-tx) > 2016-11-16 15:17:23,043 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) GenericRecoveryCoordinator(0:ffff7f000001:5857c0a5:582c6a36:2f).replay_completion(resource supplied) > 2016-11-16 15:17:23,044 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.get_current_status(0:ffff7f000001:5857c0a5:582c6a36:25, 0:ffff7f000001:5857c0a5:582c6a36:10) > 2016-11-16 15:17:23,044 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.checkOriginalStatus(0:ffff7f000001:5857c0a5:582c6a36:25, 0:ffff7f000001:5857c0a5:582c6a36:10, false) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, StateType.OS_SHADOW) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, 10) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, 11) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact) - returning StateStatus.OS_COMMITTED > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact, 11) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/Recovery/FactoryContact/0_ffff7f000001_5857c0a5_582c6a36_10, FileLock.F_RDLCK, false) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffff7f000001:5857c0a5:582c6a36:10, /Recovery/FactoryContact) > 2016-11-16 15:17:23,044 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/Recovery/FactoryContact/0_ffff7f000001_5857c0a5_582c6a36_10, java.io.FileInputStream at 4178e7fb, null) > 2016-11-16 15:17:23,045 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:5857c0a5:582c6a36:25, com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem at d2278c3, false) > 2016-11-16 15:17:23,046 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::send_request ( getCurrentStatus ) nodeId=1 requestId=9 > 2016-11-16 15:17:23,046 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ContextManager::current () > 2016-11-16 15:17:23,047 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( getCurrentStatus ) nodeId=1 requestId=9 > 2016-11-16 15:17:23,047 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request ( getCurrentStatus ) nodeId=1 requestId=9 > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, StateType.OS_SHADOW) > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, 10) > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, 11) > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, 10) > 2016-11-16 15:17:23,048 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,049 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, 11) > 2016-11-16 15:17:23,049 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,050 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,050 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 10) > 2016-11-16 15:17:23,050 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,050 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 11) > 2016-11-16 15:17:23,050 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,051 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,051 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, 10) > 2016-11-16 15:17:23,051 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,051 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, 11) > 2016-11-16 15:17:23,051 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,052 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getCurrentStatus ) nodeId=1 requestId=9 > 2016-11-16 15:17:23,052 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getCurrentStatus ) nodeId=1 requestId=9 > 2016-11-16 15:17:23,052 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getCurrentStatus ) nodeId=1 requestId=9 > 2016-11-16 15:17:23,053 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:5857c0a5:582c6a36:25) - current status = CosTransactions::StatusNoTransaction > 2016-11-16 15:17:23,053 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::send_request ( getStatus ) nodeId=1 requestId=10 > 2016-11-16 15:17:23,053 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ContextManager::current () > 2016-11-16 15:17:23,053 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( getStatus ) nodeId=1 requestId=10 > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request ( getStatus ) nodeId=1 requestId=10 > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, StateType.OS_SHADOW) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, 10) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, 11) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, 10) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, 11) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 10) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 11) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, 10) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, 11) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, StateType.OS_SHADOW) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, 10) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple, 11) > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,054 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, 10) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction, 11) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 10) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 11) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, StateType.OS_SHADOW) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, 10) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction, 11) > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:5857c0a5:582c6a36:25, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteHeuristicServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=10 > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=10 > 2016-11-16 15:17:23,055 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=10 > 2016-11-16 15:17:23,055 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:5857c0a5:582c6a36:25) - stored status = CosTransactions::StatusNoTransaction > 2016-11-16 15:17:23,057 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=8 > 2016-11-16 15:17:23,057 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=8 > 2016-11-16 15:17:23,057 DEBUG [com.arjuna.ats.jts] (Thread-109) ResourceCompletor.rollback() > 2016-11-16 15:17:23,057 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=8 > 2016-11-16 15:17:23,057 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-11-16 15:17:23,057 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-11-16 15:17:23,057 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:23,057 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:23,068 TRACE [com.arjuna.ats.jts] (Thread-109) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=11 > 2016-11-16 15:17:23,068 TRACE [com.arjuna.ats.jts] (Thread-109) ContextManager::current () > 2016-11-16 15:17:23,069 TRACE [com.arjuna.ats.jts] (Thread-109) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=11 > 2016-11-16 15:17:23,069 TRACE [com.arjuna.ats.jts] (Thread-109) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=11 > 2016-11-16 15:17:23,070 TRACE [com.arjuna.ats.jtax] (Thread-109) XAResourceRecord.rollback for < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:23,074 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.rollback(Xid=< 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 >)[id=512] > 2016-11-16 15:17:23,074 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) removeLog(xid=< 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 15:17:23,074 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) Using file /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/TestXAResourceStateStore/TestXAResource.ser for saving state of the org.jboss.as.test.jbossts.common.TestXAResource XA resource > {code} > [2] > {code} > 2016-11-16 09:45:51,329 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:7c17affe:582c1c73:28, com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem at 7b5023d7, false) > 2016-11-16 09:45:51,330 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::send_request ( getCurrentStatus ) nodeId=1 requestId=10 > 2016-11-16 09:45:51,330 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ContextManager::current () > 2016-11-16 09:45:51,330 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( getCurrentStatus ) nodeId=1 requestId=10 > 2016-11-16 09:45:51,330 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::receive_request ( getCurrentStatus ) nodeId=1 requestId=10 > 2016-11-16 09:45:51,335 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_exception ( getCurrentStatus ) nodeId=1 requestId=10 > 2016-11-16 09:45:51,335 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getCurrentStatus ) nodeId=1 requestId=10 > 2016-11-16 09:45:51,338 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_exception ( getCurrentStatus ) nodeId=1 requestId=10 > 2016-11-16 09:45:51,339 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:7c17affe:582c1c73:28) - COMM_FAILURE = dead > 2016-11-16 09:45:51,339 WARN [com.arjuna.ats.jts] (Periodic Recovery) ARJUNA022139: CORBA exception on trying to contact original process: org.omg.CORBA.BAD_OPERATION: ----------BEGIN server-side stack trace---------- > org.omg.CORBA.BAD_OPERATION: vmcid: 0x0 minor code: 0 completed: Maybe > at com.arjuna.ArjunaOTS.ArjunaTransactionPOA._invoke(ArjunaTransactionPOA.java:50) > at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654) > at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700) > at com.sun.corba.se.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:180) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:148) > at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:475) > at com.arjuna.ArjunaOTS._ArjunaFactoryStub.getCurrentStatus(_ArjunaFactoryStub.java:76) > at com.arjuna.ats.internal.jts.recovery.contact.StatusChecker.getStatus(StatusChecker.java:176) > at com.arjuna.ats.internal.jts.recovery.contact.StatusChecker.checkOriginalStatus(StatusChecker.java:144) > at com.arjuna.ats.internal.jts.recovery.contact.StatusChecker.get_current_status(StatusChecker.java:110) > at com.arjuna.ats.internal.jts.orbspecific.recovery.recoverycoordinators.GenericRecoveryCoordinator.get_status(GenericRecoveryCoordinator.java:355) > at com.arjuna.ats.internal.jts.orbspecific.recovery.recoverycoordinators.GenericRecoveryCoordinator.replay_completion(GenericRecoveryCoordinator.java:145) > at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCDefaultServant.replay_completion(JavaIdlRCDefaultServant.java:101) > at org.omg.CosTransactions.RecoveryCoordinatorPOA._invoke(RecoveryCoordinatorPOA.java:39) > at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654) > at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700) > at com.sun.corba.se.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:180) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:148) > at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:475) > at org.omg.CosTransactions._RecoveryCoordinatorStub.replay_completion(_RecoveryCoordinatorStub.java:20) > at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.recover(XAResourceRecord.java:1226) > at com.arjuna.ats.internal.jta.recovery.jts.XARecoveryResourceImple.recover(XARecoveryResourceImple.java:88) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:736) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:461) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:218) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > ----------END server-side stack trace---------- vmcid: 0x0 minor code: 0 completed: Maybe > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at com.sun.corba.se.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:921) > at com.sun.corba.se.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:116) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:590) > at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:489) > at com.sun.corba.se.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:222) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:148) > at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:475) > at com.arjuna.ArjunaOTS._ArjunaFactoryStub.getCurrentStatus(_ArjunaFactoryStub.java:76) > at com.arjuna.ats.internal.jts.recovery.contact.StatusChecker.getStatus(StatusChecker.java:176) > at com.arjuna.ats.internal.jts.recovery.contact.StatusChecker.checkOriginalStatus(StatusChecker.java:144) > at com.arjuna.ats.internal.jts.recovery.contact.StatusChecker.get_current_status(StatusChecker.java:110) > at com.arjuna.ats.internal.jts.orbspecific.recovery.recoverycoordinators.GenericRecoveryCoordinator.get_status(GenericRecoveryCoordinator.java:355) > at com.arjuna.ats.internal.jts.orbspecific.recovery.recoverycoordinators.GenericRecoveryCoordinator.replay_completion(GenericRecoveryCoordinator.java:145) > at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCDefaultServant.replay_completion(JavaIdlRCDefaultServant.java:101) > at org.omg.CosTransactions.RecoveryCoordinatorPOA._invoke(RecoveryCoordinatorPOA.java:39) > at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654) > at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700) > at com.sun.corba.se.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:180) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:148) > at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:475) > at org.omg.CosTransactions._RecoveryCoordinatorStub.replay_completion(_RecoveryCoordinatorStub.java:20) > at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.recover(XAResourceRecord.java:1226) > at com.arjuna.ats.internal.jta.recovery.jts.XARecoveryResourceImple.recover(XARecoveryResourceImple.java:88) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:736) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:461) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:218) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > 2016-11-16 09:45:51,339 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > 2016-11-16 09:45:51,339 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.write_committed(0:ffff7f000001:7c17affe:582c1c73:14, /Recovery/FactoryContact) > 2016-11-16 09:45:51,339 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.write_state(0:ffff7f000001:7c17affe:582c1c73:14, /Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 09:45:51,339 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:14, /Recovery/FactoryContact, StateType.OS_ORIGINAL) > 2016-11-16 09:45:51,339 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:14, /Recovery/FactoryContact, 11) > 2016-11-16 09:45:51,339 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/Recovery/FactoryContact/0_ffff7f000001_7c17affe_582c1c73_14, FileLock.F_WRLCK, true) > 2016-11-16 09:45:51,345 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/Recovery/FactoryContact/0_ffff7f000001_7c17affe_582c1c73_14, null, java.io.FileOutputStream at 33746342) > 2016-11-16 09:45:51,346 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) CachedRecoveredTransaction created [0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction] > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:ffff7f000001:7c17affe:582c1c73:28 ) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction(0:ffff7f000001:7c17affe:582c1c73:28) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ArjunaTransactionImple::ArjunaTransactionImple ( 0:ffff7f000001:7c17affe:582c1c73:28 ) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ServerTransaction::ServerTransaction ( 0:ffff7f000001:7c17affe:582c1c73:28 ) > 2016-11-16 09:45:51,347 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) RecoveredServerTransaction 0:ffff7f000001:7c17affe:582c1c73:28 created > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_SHADOW) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 10) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction, 11) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:ffff7f000001:7c17affe:582c1c73:28 ) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction(0:ffff7f000001:7c17affe:582c1c73:28) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ArjunaTransactionImple::ArjunaTransactionImple ( 0:ffff7f000001:7c17affe:582c1c73:28 ) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.jts] (Periodic Recovery) ServerTransaction::ServerTransaction ( 0:ffff7f000001:7c17affe:582c1c73:28 ) > 2016-11-16 09:45:51,347 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) RecoveredServerTransaction 0:ffff7f000001:7c17affe:582c1c73:28 created > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteServerTransaction, StateType.OS_SHADOW) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteServerTransaction, 10) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteServerTransaction, StateType.OS_ORIGINAL) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteServerTransaction, 11) > 2016-11-16 09:45:51,347 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/AssumedCompleteServerTransaction) - returning StateStatus.OS_UNKNOWN > 2016-11-16 09:45:51,347 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) AssumedCompleteServerTransaction 0:ffff7f000001:7c17affe:582c1c73:28 created > 2016-11-16 09:45:51,347 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) CachedRecoveredTransaction.get_status [0:ffff7f000001:7c17affe:582c1c73:28, /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction] = CosTransactions::StatusRolledBack > 2016-11-16 09:45:51,348 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=9 > 2016-11-16 09:45:51,348 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=9 > 2016-11-16 09:45:51,348 DEBUG [com.arjuna.ats.jts] (Thread-108) ResourceCompletor.rollback() > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jts] (Thread-108) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=11 > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jts] (Thread-108) ContextManager::current () > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=9 > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-11-16 09:45:51,349 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jts] (Thread-108) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=11 > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 09:45:51,349 TRACE [com.arjuna.ats.jts] (Thread-108) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=11 > 2016-11-16 09:45:51,350 TRACE [com.arjuna.ats.jtax] (Thread-108) XAResourceRecord.rollback for < 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 09:45:51,354 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.rollback(Xid=< 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 >)[id=947] > 2016-11-16 09:45:51,354 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) removeLog(xid=< 4660, 64, 64, 12700100004200042000000000000000000000000000000000000000000000000000, 12700100004200042000000000000000000000000000000000000000000000000000 > > 2016-11-16 09:45:51,354 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) Using file /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/TestXAResourceStateStore/TestXAResource.ser for saving state of the org.jboss.as.test.jbossts.common.TestXAResource XA resource > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 5 08:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Dec 2016 08:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2808: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 5 08:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Dec 2016 08:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2808: -------------------------------- Priority: Critical (was: Major) > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 06:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Dec 2016 06:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2811) BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2811: ----------------------------------- Summary: BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received Key: JBTM-2811 URL: https://issues.jboss.org/browse/JBTM-2811 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next The lock is obtained before the receive but then the receive doesn't release the lock until after and so if a message is received in the middle tpgetreply is not notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 06:59:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Dec 2016 06:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2811) BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1098 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received > -------------------------------------------------------------------------------------------------------- > > Key: JBTM-2811 > URL: https://issues.jboss.org/browse/JBTM-2811 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The lock is obtained before the receive but then the receive doesn't release the lock until after and so if a message is received in the middle tpgetreply is not notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 07:12:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 6 Dec 2016 07:12:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2812) Calling forget on an XAResource should always remove the corresponding log In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2812: -------------------------------------- Summary: Calling forget on an XAResource should always remove the corresponding log Key: JBTM-2812 URL: https://issues.jboss.org/browse/JBTM-2812 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.4.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next During abort processing (in BasicAction) we attempt to forgetHeuristics and then remove the participant log. The fix for JBTM-2728 changed this behaviour such that the log is retained if the resource forget operation fails. This is a change in behaviour and needs to be reverted. Note that the resource will still eventually be told to forget during normal recovery processing for orphans (provided we have configured presumed abort semantics): # our XARecoveryModule asks the resource for its pending branches (via the xa_recover() peration); # if the xid is one of ours and if we no longer have a record for it then we call rollback on it presumed abort); # the reosource uses the rollback call to tell us that the branch was already heuristically rolled back so we call forget -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 07:32:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 6 Dec 2016 07:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2812) Calling forget on an XAResource should always remove the corresponding log In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1099 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Calling forget on an XAResource should always remove the corresponding log > -------------------------------------------------------------------------- > > Key: JBTM-2812 > URL: https://issues.jboss.org/browse/JBTM-2812 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > During abort processing (in BasicAction) we attempt to forgetHeuristics and then remove the participant log. The fix for JBTM-2728 changed this behaviour such that the log is retained if the resource forget operation fails. This is a change in behaviour and needs to be reverted. > Note that the resource will still eventually be told to forget during normal recovery processing for orphans (provided we have configured presumed abort semantics): > # our XARecoveryModule asks the resource for its pending branches (via the xa_recover() peration); > # if the xid is one of ours and if we no longer have a record for it then we call rollback on it presumed abort); > # the reosource uses the rollback call to tell us that the branch was already heuristically rolled back so we call forget -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 09:06:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Dec 2016 09:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2805) Karaf fails to build in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2805: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Karaf fails to build in CI > -------------------------- > > Key: JBTM-2805 > URL: https://issues.jboss.org/browse/JBTM-2805 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Amos Feng > > We should try to avoid building Karaf in CI. > At this point it fails to build. > {code} > [INFO] --- maven-resources-plugin:2.7:resources (process-resources) @ apache-karaf-minimal --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 4 resources > [INFO] > [INFO] --- karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) @ apache-karaf-minimal --- > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Apache Karaf ....................................... SUCCESS [ 4.795 s] > [INFO] Apache Karaf :: JAAS ............................... SUCCESS [ 0.017 s] > [INFO] Apache Karaf :: JAAS :: Boot ....................... SUCCESS [ 2.413 s] > [INFO] Apache Karaf :: Util ............................... SUCCESS [ 4.843 s] > [INFO] Apache Karaf :: Main ............................... SUCCESS [ 11.143 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Features :: Extension .............. SUCCESS [ 0.157 s] > [INFO] Apache Karaf :: Service ............................ SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Service :: Guard ................... SUCCESS [ 8.831 s] > [INFO] Apache Karaf :: Shell .............................. SUCCESS [ 0.010 s] > [INFO] Apache Karaf :: Shell :: Core ...................... SUCCESS [ 6.523 s] > [INFO] Apache Karaf :: Tooling ............................ SUCCESS [ 0.013 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin for Services Metadata SUCCESS [ 58.898 s] > [INFO] Apache Karaf :: Features :: Core ................... SUCCESS [ 5.522 s] > [INFO] Apache Karaf :: Features :: Command ................ SUCCESS [ 0.845 s] > [INFO] Apache Karaf :: KAR :: Core ........................ SUCCESS [ 0.869 s] > [INFO] Apache Karaf :: JAAS :: Config ..................... SUCCESS [ 7.906 s] > [INFO] Apache Karaf :: JAAS :: Modules .................... SUCCESS [ 18.313 s] > [INFO] Apache Karaf :: Bundle ............................. SUCCESS [ 0.009 s] > [INFO] Apache Karaf :: Bundle :: Core ..................... SUCCESS [ 1.076 s] > [INFO] Apache Karaf :: Bundle :: BlueprintStateService .... SUCCESS [ 0.095 s] > [INFO] Apache Karaf :: Bundle :: SpringStateService ....... SUCCESS [ 8.690 s] > [INFO] Apache Karaf :: ConfigAdmin :: Core ................ SUCCESS [ 0.454 s] > [INFO] Apache Karaf :: Tooling :: Utils ................... SUCCESS [ 2.911 s] > [INFO] Apache Karaf :: Deployer ........................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Deployer :: Blueprint .............. SUCCESS [ 2.328 s] > [INFO] Apache Karaf :: Deployer :: Spring ................. SUCCESS [ 0.166 s] > [INFO] Apache Karaf :: Demos :: Profiles :: Registry ...... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Profile :: Core .................... SUCCESS [ 9.123 s] > [INFO] Apache Karaf :: Instance :: Core ................... SUCCESS [ 1.096 s] > [INFO] Apache Karaf :: Package :: Core .................... SUCCESS [ 0.316 s] > [INFO] Apache Karaf :: HTTP :: Core ....................... SUCCESS [ 3.623 s] > [INFO] Apache Karaf :: Service :: Core .................... SUCCESS [ 0.323 s] > [INFO] Apache Karaf :: Log :: Core ........................ SUCCESS [ 4.122 s] > [INFO] Apache Karaf :: Deployer :: Features ............... SUCCESS [ 0.568 s] > [INFO] Apache Karaf :: Deployer :: Karaf Archive (.kar) ... SUCCESS [ 0.491 s] > [INFO] Apache Karaf :: Deployer :: Wrap Non OSGi Jar ...... SUCCESS [ 0.100 s] > [INFO] Apache Karaf :: Shell :: Various Commands .......... SUCCESS [ 0.471 s] > [INFO] Apache Karaf :: Shell :: Console ................... SUCCESS [ 3.362 s] > [INFO] Apache Karaf :: Shell :: Table ..................... SUCCESS [ 0.111 s] > [INFO] Apache Karaf :: Shell :: SSH ....................... SUCCESS [ 2.032 s] > [INFO] Apache Karaf :: JAAS :: Jasypt Encryption .......... SUCCESS [ 2.921 s] > [INFO] Apache Karaf :: JAAS :: Command .................... SUCCESS [ 0.492 s] > [INFO] Apache Karaf :: JAAS :: Blueprint .................. SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Config ........ SUCCESS [ 0.081 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Jasypt ........ SUCCESS [ 1.509 s] > [INFO] Apache Karaf :: Client ............................. SUCCESS [ 0.164 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.212 s] > [INFO] Apache Karaf :: System :: Core ..................... SUCCESS [ 0.329 s] > [INFO] Apache Karaf :: Web :: Core ........................ SUCCESS [ 0.328 s] > [INFO] Apache Karaf :: Wrapper :: Core .................... SUCCESS [ 0.667 s] > [INFO] Apache Karaf :: Web Console ........................ SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Web Console :: Console ............. SUCCESS [ 3.205 s] > [INFO] Apache Karaf :: Web Console :: Features Plugin ..... SUCCESS [ 0.559 s] > [INFO] Apache Karaf :: Web Console :: Gogo Plugin ......... SUCCESS [ 0.617 s] > [INFO] Apache Karaf :: Web Console :: HTTP Plugin ......... SUCCESS [ 0.567 s] > [INFO] Apache Karaf :: Web Console :: Instance Plugin ..... SUCCESS [ 0.224 s] > [INFO] Apache Karaf :: Exception .......................... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Scheduler :: Core .................. SUCCESS [ 3.628 s] > [INFO] Apache Karaf :: Declarative Services (DS) .......... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: SCR :: Shell Commands .............. SUCCESS [ 3.391 s] > [INFO] Apache Karaf :: SCR :: Management MBeans ........... SUCCESS [ 1.491 s] > [INFO] Apache Karaf :: SCR :: Bundle State ................ SUCCESS [ 0.176 s] > [INFO] Apache Karaf :: SCR :: Examples .................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: SCR :: Examples :: Basic Service ... SUCCESS [ 0.060 s] > [INFO] Apache Karaf :: SCR :: Examples :: Managed Services SUCCESS [ 0.076 s] > [INFO] Apache Karaf :: SCR :: Examples :: Component Factories SUCCESS [ 0.063 s] > [INFO] Apache Karaf :: Diagnostic ......................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Diagnostic :: Boot ................. SUCCESS [ 0.096 s] > [INFO] Apache Karaf :: Diagnostic :: Core ................. SUCCESS [ 0.748 s] > [INFO] Apache Karaf :: OBR :: Core ........................ SUCCESS [ 1.771 s] > [INFO] Apache Karaf :: JNDI :: Core ....................... SUCCESS [ 1.765 s] > [INFO] Apache Karaf :: JDBC :: Core ....................... SUCCESS [ 0.410 s] > [INFO] Apache Karaf :: JMS :: Core ........................ SUCCESS [ 6.591 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Parent ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Hibernate ................... SUCCESS [ 8.436 s] > [INFO] Apache Karaf :: OSGi Services :: Coordinator ....... SUCCESS [ 1.763 s] > [INFO] Apache Karaf :: OSGi Services :: EventAdmin ........ SUCCESS [ 1.511 s] > [INFO] Apache Karaf :: OSGi Services :: Static ConfigAdmin SUCCESS [ 0.087 s] > [INFO] Apache Karaf :: OSGi Services ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Subsystem :: Core .................. SUCCESS [ 5.008 s] > [INFO] Apache Karaf :: OSGi Services :: Event ............. SUCCESS [ 1.709 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin ...... SUCCESS [ 7.875 s] > [INFO] Apache Karaf :: Assemblies ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Assemblies :: Features ............. SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Base ..... SUCCESS [ 3.828 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Framework SUCCESS [ 2.555 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Static ... SUCCESS [ 1.836 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Standard . SUCCESS [01:12 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Spring ... SUCCESS [01:19 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Enterprise SUCCESS [ 42.574 s] > [INFO] Apache Karaf :: Assemblies :: Demos ................ SUCCESS [ 0.075 s] > [INFO] Apache Karaf :: Assemblies :: Minimal Distribution . FAILURE [ 0.097 s] > [INFO] Apache Karaf :: Assemblies :: Default Distribution . SKIPPED > [INFO] Apache Karaf :: Demos .............................. SKIPPED > [INFO] Apache Karaf :: Demos :: Web ....................... SKIPPED > [INFO] Apache Karaf :: Demos :: Branding :: Shell ......... SKIPPED > [INFO] Apache Karaf :: Demos :: Command :: Extend Console . SKIPPED > [INFO] Apache Karaf :: Demos :: Demo Dump provider ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer .................. SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Kar ........... SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Bundle ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Dynamic Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Static Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles .................. SKIPPED > [INFO] Apache Karaf :: Archetypes ......................... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Assembly Archetype ... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Command Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Feature Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Kar Archetype ........ SKIPPED > [INFO] Apache Karaf :: Archetypes :: Bundle Archetype ..... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Blueprint Archetype .. SKIPPED > [INFO] Apache Karaf :: Integration Tests .................. SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 07:17 min > [INFO] Finished at: 2016-11-29T00:19:34+00:00 > [INFO] Final Memory: 165M/1003M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project apache-karaf-minimal: Unable to parse configuration of mojo org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly for parameter pidsToExtract: Cannot assign configuration entry 'pidsToExtract' with value '!jmx.acl.*, > [ERROR] !org.apache.karaf.command.acl.*, > [ERROR] *' of type java.lang.String to property of type java.util.List > [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/PluginConfigurationException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :apache-karaf-minimal > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 10:03:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Dec 2016 10:03:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2811) BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2811: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received > -------------------------------------------------------------------------------------------------------- > > Key: JBTM-2811 > URL: https://issues.jboss.org/browse/JBTM-2811 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The lock is obtained before the receive but then the receive doesn't release the lock until after and so if a message is received in the middle tpgetreply is not notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 6 13:03:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Dec 2016 13:03:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13334845#comment-13334845 ] Tom Jenkinson commented on JBTM-2790: ------------------------------------- The message to pause the server does not seem to be received at testsui1 14046 is the message ID I think on the app server Stomp sent but I can;t see it getting received. > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 02:47:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 7 Dec 2016 02:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2792) Participant is not rolled-back when RMERR thrown during prepare phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka closed JBTM-2792. --------------------------------- Resolution: Rejected See Mike's explanation at https://issues.jboss.org/browse/JBEAP-7417?focusedCommentId=13334487#comment-13334487 > Participant is not rolled-back when RMERR thrown during prepare phase > --------------------------------------------------------------------- > > Key: JBTM-2792 > URL: https://issues.jboss.org/browse/JBTM-2792 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Attachments: JPAProxyCrashRecoveryTestCase_prepareHalt_jta_server-5.3.3.Final.log, JPAProxyCrashRecoveryTestCase_prepareHalt_jta_server-5.3.5.Final.log > > > I do experience trouble - or maybe different behavior against older version of Narayana - with forgetting transaction log when failure is caused by jdbc driver throws XAException.XAER_RMERR during prepare phase of 2PC. > The test scenario is following > {quote} > * prepare db/jms XA > * stop connection to db/jms > * prepare test XA > * commit db/jms XA (connection is down - jdbc driver throws?XAException.XAER_RMERR) > * client gets javax.transaction.TransactionRolledbackException from server side > * trying to abort transaction > * rollback of db resource but connection is down > * rolback test XA???? > * connection is started again > * expected behaviour: periodic recovery -> rollback db XA > {quote} > For current Narayana version (tested with 5.3.5 and 5.4.1.snapshot) the periodic recovery does not rolled back the participant during recovery cycle. > For Narayana 5.3.3.Final periodic recovery votes for rollback (ROLLBACK)[1]. > Narayan 5.3.5.Final ends with voting for doing nothing (JTATransactionLogXAResourceOrphanFilter.LEAVE_ALONE)[2]. > It seems to me that's caused by fact that directly after transaction commit fails (because of not existing connection) for previous version of Narayana transaction record about participant was removed from txn log [3]. But in current version the transaction record is left in log[4] and orphan filters do not vote for roll-backing in bottom-up phase later on. > [1] > {code} > 2016-11-21 09:01:25,576 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:-70f14116:5832a97b:26, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_UNKNOWN2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is 12016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is null2016-11-21 09:01:25,576 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ABSTAIN2016-11-21 09:01:25,577 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-70f14116:5832a97b:26, node_name=1, branch_uid=0:ffff7f000001:-70f14116:5832a97b:29, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is 1 > {code} > [2] > {code} > 2016-11-21 09:18:03,008 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found record for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-359c90f5:5832ad62:27, node_name=1, branch_uid=0:ffff7f000001:-359c90f5:5832ad62:2a, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >2016-11-21 09:18:03,008 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted LEAVE_ALONE > {code} > [3] > {code} > 2016-11-21 09:00:33,981 TRACE [com.arjuna.ats.arjuna] (default task-8) BasicAction::updateState() for action-id 0:ffff7f000001:-70f14116:5832a97b:262016-11-21 09:00:33,981 TRACE [com.arjuna.ats.arjuna] (default task-8) FileSystemStore.remove_committed(0:ffff7f000001:-70f14116:5832a97b:26, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)2016-11-21 09:00:33,981 TRACE [com.arjuna.ats.arjuna] (default task-8) ShadowingStore.remove_state(0:ffff7f000001:-70f14116:5832a97b:26, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) > {code} > [4] > {code} > 2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) Packing action status of ActionStatus.ABORTING2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) FileSystemStore.write_committed(0:ffff7f000001:-359c90f5:5832ad62:27, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) ShadowingStore.write_state(0:ffff7f000001:-359c90f5:5832ad62:27, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)2016-11-21 09:17:11,785 TRACE [com.arjuna.ats.arjuna] (default task-8) ShadowingStore.genPathName(0:ffff7f000001:-359c90f5:5832ad62:27, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 05:38:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 7 Dec 2016 05:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2812: ----------------------------------- Summary: Retain a log if a forget call on a resource fails (was: Calling forget on an XAResource should always remove the corresponding log) > Retain a log if a forget call on a resource fails > ------------------------------------------------- > > Key: JBTM-2812 > URL: https://issues.jboss.org/browse/JBTM-2812 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > During abort processing (in BasicAction) we attempt to forgetHeuristics and then remove the participant log. The fix for JBTM-2728 changed this behaviour such that the log is retained if the resource forget operation fails. This is a change in behaviour and needs to be reverted. > Note that the resource will still eventually be told to forget during normal recovery processing for orphans (provided we have configured presumed abort semantics): > # our XARecoveryModule asks the resource for its pending branches (via the xa_recover() peration); > # if the xid is one of ours and if we no longer have a record for it then we call rollback on it presumed abort); > # the reosource uses the rollback call to tell us that the branch was already heuristically rolled back so we call forget -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 05:47:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 7 Dec 2016 05:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2812: ----------------------------------- Description: When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling). (was: During abort processing (in BasicAction) we attempt to forgetHeuristics and then remove the participant log. The fix for JBTM-2728 changed this behaviour such that the log is retained if the resource forget operation fails. This is a change in behaviour and needs to be reverted. Note that the resource will still eventually be told to forget during normal recovery processing for orphans (provided we have configured presumed abort semantics): # our XARecoveryModule asks the resource for its pending branches (via the xa_recover() peration); # if the xid is one of ours and if we no longer have a record for it then we call rollback on it presumed abort); # the reosource uses the rollback call to tell us that the branch was already heuristically rolled back so we call forget) > Retain a log if a forget call on a resource fails > ------------------------------------------------- > > Key: JBTM-2812 > URL: https://issues.jboss.org/browse/JBTM-2812 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 07:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Dec 2016 07:22:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13334845#comment-13334845 ] Tom Jenkinson edited comment on JBTM-2790 at 12/7/16 7:21 AM: -------------------------------------------------------------- Fundamentally the issue is that stomp side sends the message (14046 AKA JMSMessageID aab18eed-9a46-11e6-93e9-525400b0f360) but the C side doesn't receive it: This is it being sent by the app server: 2016-10-25 01:04:58,828 DEBUG [org.codehaus.stomp.jms.ProtocolConverter] (Thread-16 (ActiveMQ-client-global-threads-20571710)) Locking output handler to ensure that we don't mux signals This is the C side blocking wait: 2016-10-25 01:04:57,273 [0x000009b4] TRACE (AtmiBrokerLogc :84 ) - stomp_read_line was (Author: tomjenkinson): The message to pause the server does not seem to be received at testsui1 14046 is the message ID I think on the app server Stomp sent but I can;t see it getting received. > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 08:00:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Dec 2016 08:00:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1101 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 08:01:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Dec 2016 08:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2790: -------------------------------- Priority: Major (was: Minor) > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 08:43:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 7 Dec 2016 08:43:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka moved JBEAP-7736 to JBTM-2813: ---------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2813 (was: JBEAP-7736) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JTS (was: Transactions) Affects Version/s: 5.4.0.Final (was: 7.1.0.DR9) > Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2813 > URL: https://issues.jboss.org/browse/JBTM-2813 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip > > > This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it. > That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected. > When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources) > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 7 11:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Dec 2016 11:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13335477#comment-13335477 ] Tom Jenkinson commented on JBTM-2790: ------------------------------------- With the additional log patch I added you can do the following to check if it is a problem with data not received on the C side: >From the test -output.txt PauseDomainTest [0x00000ea0] INFO (AtmiBrokerServer :645 ) - Server waiting for requests... Next thread: 2016-12-07 14:47:05,398 [0x00000a48] DEBUG (HybridConnectionImpl :128 ) - Sending CONNECT stomp_read_line: remote 61613 local 49766 x46 then a gap 2016-12-07 14:47:11,818 [0x00000a48] TRACE (AtmiBrokerLogc :84 ) - stomp_read_line: remote 61613 local 49766 2016-12-07 14:47:11,818 [0x00000a48] TRACE (AtmiBrokerLogc :84 ) - Read the command MESSAGE 2016-12-07 14:47:11,833 [0x00000a48] DEBUG (HybridStompEndpointQueue :569 ) - Acked: ID:08d26c84-bc8c-11e6-9f10-525400b0f360 2016-12-07 14:47:11,849 [0x00000a48] DEBUG (AtmiBrokerAdmin :43 ) - get request is pause grep -a "08d26c84-bc8c-11e6-9f10-525400b0f360\|49766" server.log > out 2016-12-07 14:47:11,816 DEBUG [org.codehaus.stomp.jms.StompSubscription] (Thread-17 (ActiveMQ-client-global-threads-4585758)) Received from HQ: ID:08d26c84-bc8c-11e6-9f10-525400b0f360 2016-12-07 14:47:11,869 DEBUG [org.codehaus.stomp.tcp.TcpTransport] (Thread-17 (ActiveMQ-client-global-threads-4585758)) Flushed message to server side: remote - 49766 local - 61613 Also, I observed on both Windows and Linux that both server messages startup should be printed. So when the log is incomplete it is possible that those messages are just being missed. However if it was just missed messages the Stomp side wouldn't be blocking waiting for the ack so I think the data is not fully flushed. Someone on the internet said to make sure a \n is flushed for the remote side but we do this so I don't think it's that. > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 8 15:38:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 8 Dec 2016 15:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2814) Migrate Mark Little's TransactionalVert.x work to narayana In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2814: -------------------------------------- Summary: Migrate Mark Little's TransactionalVert.x work to narayana Key: JBTM-2814 URL: https://issues.jboss.org/browse/JBTM-2814 Project: JBoss Transaction Manager Issue Type: Feature Request Components: vertx Affects Versions: 5.next Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Fix For: 5.next Migrate Mark's TransactionalVert.x repo (https://github.com/nmcl/TransactionalVert.x) to the narayana repo and port to Vert.x 3 in the process. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 8 15:47:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 8 Dec 2016 15:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2814) Migrate Mark Little's TransactionalVert.x work to narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1103 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Migrate Mark Little's TransactionalVert.x work to narayana > ---------------------------------------------------------- > > Key: JBTM-2814 > URL: https://issues.jboss.org/browse/JBTM-2814 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: vertx > Affects Versions: 5.next > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Migrate Mark's TransactionalVert.x repo (https://github.com/nmcl/TransactionalVert.x) to the narayana repo and port to Vert.x 3 in the process. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 9 15:26:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 9 Dec 2016 15:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2701: --------------------------------- > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > 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.2.21, 5.3.5.Final > > > 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 (v7.2.3#72005) From issues at jboss.org Fri Dec 9 15:26:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 9 Dec 2016 15:26:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ 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.2.21 > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > 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.2.21, 5.3.5.Final > > > 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 (v7.2.3#72005) From issues at jboss.org Fri Dec 9 15:27:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 9 Dec 2016 15:27:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2701: -------------------------------- Priority: Critical (was: Minor) > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > 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: Critical > Fix For: 5.2.21, 5.3.5.Final > > > 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 (v7.2.3#72005) From issues at jboss.org Sun Dec 11 13:15:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 11 Dec 2016 13:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2701. --------------------------------- Resolution: Done > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > 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: Critical > Fix For: 5.2.21, 5.3.5.Final > > > 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 (v7.2.3#72005) From issues at jboss.org Mon Dec 12 06:00:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 12 Dec 2016 06:00:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2815) Transaction manager runtime configuration is not enriched with system properties from standalone xml In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2815: ------------------------------------- Summary: Transaction manager runtime configuration is not enriched with system properties from standalone xml Key: JBTM-2815 URL: https://issues.jboss.org/browse/JBTM-2815 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Critical I can see trouble and regression against behavior of 7.0.0.GA (and other prior 7.1.0 DR versions) where configuration of transaction manager which is defined inside of setting MBeans is not enriched from system properties which are defined as part of standalone .xm file. When system property is set in standalone xml file as {code} {code} then it's not propagated to {{RecoveryEnvironmentBean}} when container is started. I could see that method loading system properties at AbstractPropertiesFactory (https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna/common/util/propertyservice/AbstractPropertiesFactory.java#L119) does not provide those which are part of the container config. That worked with DR8 fine. I didn't go deeper if this is really issue of TM/integration or some change in container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 12 06:01:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 12 Dec 2016 06:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2815) Transaction manager runtime configuration is not enriched with system properties from standalone xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2815: ------------------------------------- Assignee: Tom Jenkinson > Transaction manager runtime configuration is not enriched with system properties from standalone xml > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2815 > URL: https://issues.jboss.org/browse/JBTM-2815 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > > I can see trouble and regression against behavior of 7.0.0.GA (and other prior 7.1.0 DR versions) where configuration of transaction manager which is defined inside of setting MBeans is not enriched from system properties which are defined as part of standalone .xm file. > When system property is set in standalone xml file as > {code} > > > > {code} > then it's not propagated to {{RecoveryEnvironmentBean}} when container is started. > I could see that method loading system properties at AbstractPropertiesFactory (https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna/common/util/propertyservice/AbstractPropertiesFactory.java#L119) does not provide those which are part of the container config. That worked with DR8 fine. I didn't go deeper if this is really issue of TM/integration or some change in container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 12 06:01:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 12 Dec 2016 06:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2815) Transaction manager runtime configuration is not enriched with system properties from standalone xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2815: ---------------------------------- Affects Version/s: 5.4.0.Final > Transaction manager runtime configuration is not enriched with system properties from standalone xml > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2815 > URL: https://issues.jboss.org/browse/JBTM-2815 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > > I can see trouble and regression against behavior of 7.0.0.GA (and other prior 7.1.0 DR versions) where configuration of transaction manager which is defined inside of setting MBeans is not enriched from system properties which are defined as part of standalone .xm file. > When system property is set in standalone xml file as > {code} > > > > {code} > then it's not propagated to {{RecoveryEnvironmentBean}} when container is started. > I could see that method loading system properties at AbstractPropertiesFactory (https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna/common/util/propertyservice/AbstractPropertiesFactory.java#L119) does not provide those which are part of the container config. That worked with DR8 fine. I didn't go deeper if this is really issue of TM/integration or some change in container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 12 23:07:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 12 Dec 2016 23:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: Amos Feng created JBTM-2816: ------------------------------- Summary: Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 Key: JBTM-2816 URL: https://issues.jboss.org/browse/JBTM-2816 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System, Demonstrator Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 12 23:11:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 12 Dec 2016 23:11:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #183 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 13 06:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Dec 2016 06:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2815) Transaction manager runtime configuration is not enriched with system properties from standalone xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2815. ------------------------------- Resolution: Migrated to another ITS Migrated to another ITS https://issues.jboss.org/browse/WFLY-7785 > Transaction manager runtime configuration is not enriched with system properties from standalone xml > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2815 > URL: https://issues.jboss.org/browse/JBTM-2815 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > > I can see trouble and regression against behavior of 7.0.0.GA (and other prior 7.1.0 DR versions) where configuration of transaction manager which is defined inside of setting MBeans is not enriched from system properties which are defined as part of standalone .xm file. > When system property is set in standalone xml file as > {code} > > > > {code} > then it's not propagated to {{RecoveryEnvironmentBean}} when container is started. > I could see that method loading system properties at AbstractPropertiesFactory (https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna/common/util/propertyservice/AbstractPropertiesFactory.java#L119) does not provide those which are part of the container config. That worked with DR8 fine. I didn't go deeper if this is really issue of TM/integration or some change in container. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 13 08:29:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Dec 2016 08:29:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2817) Server startup hanging in InboundBridgeRecoveryTestCase#testCrashAfterPrepareInParticipantResource In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2817: ----------------------------------- Summary: Server startup hanging in InboundBridgeRecoveryTestCase#testCrashAfterPrepareInParticipantResource Key: JBTM-2817 URL: https://issues.jboss.org/browse/JBTM-2817 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Reporter: Tom Jenkinson Assignee: Michael Musgrove Priority: Blocker Fix For: 5.next Since WFLY-6493 - WildFly won't respond to HTTP calls during startup now causing hang in recovery in bridge: {code} I have this from the debugger hanging: "MSC service thread 1-8 at 2725" prio=5 tid=0x1a nid=NA runnable java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:170) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:285) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:454) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.put(ClientInvocationBuilder.java:175) at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:244) at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202) at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153) at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62) at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.(InboundBridgeManager.java:60) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50) - locked <0x2aba> (a java.lang.Class) at org.wildfly.extension.rts.service.InboundBridgeService.start(InboundBridgeService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 13 10:16:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 13 Dec 2016 10:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2814) Migrate Mark Little's TransactionalVert.x work to narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2814: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Migrate Mark Little's TransactionalVert.x work to narayana > ---------------------------------------------------------- > > Key: JBTM-2814 > URL: https://issues.jboss.org/browse/JBTM-2814 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: vertx > Affects Versions: 5.next > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Migrate Mark's TransactionalVert.x repo (https://github.com/nmcl/TransactionalVert.x) to the narayana repo and port to Vert.x 3 in the process. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 13 10:17:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 13 Dec 2016 10:17:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2812: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Retain a log if a forget call on a resource fails > ------------------------------------------------- > > Key: JBTM-2812 > URL: https://issues.jboss.org/browse/JBTM-2812 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 13 12:59:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 13 Dec 2016 12:59:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1106 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2813 > URL: https://issues.jboss.org/browse/JBTM-2813 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip > > > This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it. > That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected. > When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources) > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 14 06:01:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 14 Dec 2016 06:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2818: -------------------------------------- Summary: Document tooling operation for deleting participants Key: JBTM-2818 URL: https://issues.jboss.org/browse/JBTM-2818 Project: JBoss Transaction Manager Issue Type: Bug Components: Documentation Affects Versions: 5.4.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 14 06:19:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 14 Dec 2016 06:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #41 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Document tooling operation for deleting participants > ---------------------------------------------------- > > Key: JBTM-2818 > URL: https://issues.jboss.org/browse/JBTM-2818 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 05:01:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 15 Dec 2016 05:01:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2818: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Document tooling operation for deleting participants > ---------------------------------------------------- > > Key: JBTM-2818 > URL: https://issues.jboss.org/browse/JBTM-2818 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 05:56:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Dec 2016 05:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2819: ------------------------------------- Summary: Recover operation does not work for participant of JCA type transactions Key: JBTM-2819 URL: https://issues.jboss.org/browse/JBTM-2819 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following {code} [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe {"outcome" => "success"} [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) { "outcome" => "success", "result" => { "expose-all-logs" => false, "type" => "default", "transactions" => { "0:ffff7f000001:-4cecb39b:585109e2:31" => { "age-in-seconds" => undefined, "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", "jmx-name" => undefined, "type" => "CosTransactions/XAResourceRecord", "participants" => undefined }, "0:ffff7f000001:-4cecb39b:585109e2:28" => { "age-in-seconds" => "1481798762", "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", "jmx-name" => undefined, "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { "eis-product-name" => "unavailable", "eis-product-version" => "unavailable", "jmx-name" => undefined, "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", "status" => "HEURISTIC_ROLLBACK", "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" }} } } } } [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover {"outcome" => "success"} [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource { "outcome" => "success", "result" => { "eis-product-name" => "unavailable", "eis-product-version" => "unavailable", "jmx-name" => undefined, "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", "status" => "HEURISTIC_ROLLBACK", "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" } } {code} I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 05:57:02 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Dec 2016 05:57:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2819: ---------------------------------- Affects Version/s: 5.4.0.Final > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 05:57:02 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Dec 2016 05:57:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2819: ------------------------------------- Assignee: Michael Musgrove > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 05:57:02 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Dec 2016 05:57:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2819: ---------------------------------- Attachment: heuristic-rollback-objectstore.zip > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 06:03:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 15 Dec 2016 06:03:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2813: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2813 > URL: https://issues.jboss.org/browse/JBTM-2813 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip > > > This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it. > That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected. > When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources) > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 06:17:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 06:17:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1107: -------------------------------- Issue Type: Feature Request (was: Enhancement) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 07:04:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 15 Dec 2016 07:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339079#comment-13339079 ] Michael Musgrove commented on JBTM-2819: ---------------------------------------- The participant has already rolled back (its status is HEURISTIC_ROLLBACK) and therefore it is too late to attempt another commit. The only states where we will reattempt the commit/abort is if we do not know what the resource did:- ie HEURISTIC_MIXED or HEURISTIC_HAZARD. I can either reject this JIRA or make it a documentation issue so that it is clear under what circumstances the recover operation can succeed. FYI the bit of code that indicates why the recover attempt fails is here: https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/osb/mbean/LogRecordWrapper.java#L131 > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 14:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 14:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2799) Javadoc Tomcat module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2799: --------------------------------- > Javadoc Tomcat module > --------------------- > > Key: JBTM-2799 > URL: https://issues.jboss.org/browse/JBTM-2799 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 14:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 14:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2799) Javadoc Tomcat module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2799: -------------------------------- Fix Version/s: 5.later (was: 5.next) > Javadoc Tomcat module > --------------------- > > Key: JBTM-2799 > URL: https://issues.jboss.org/browse/JBTM-2799 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 14:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 14:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2806) Javadoc JMS module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2806: -------------------------------- Fix Version/s: 5.later (was: 5.next) > Javadoc JMS module > ------------------ > > Key: JBTM-2806 > URL: https://issues.jboss.org/browse/JBTM-2806 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 14:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 14:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1107: -------------------------------- Fix Version/s: 5.later > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.later > > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 14:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 14:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2794: --------------------------------- > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 14:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Dec 2016 14:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2794: -------------------------------- Fix Version/s: 5.later (was: 5.next) > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 22:32:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 15 Dec 2016 22:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2816: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 22:36:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 15 Dec 2016 22:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2820) Quickstart build karaf failed due to can not find the org.apache.felix:gogo-parent 1.0.1-SNAPSHOT In-Reply-To: References: Message-ID: Amos Feng created JBTM-2820: ------------------------------- Summary: Quickstart build karaf failed due to can not find the org.apache.felix:gogo-parent 1.0.1-SNAPSHOT Key: JBTM-2820 URL: https://issues.jboss.org/browse/JBTM-2820 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator Reporter: Amos Feng Assignee: Amos Feng http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/26 {code} [ERROR] Failed to execute goal on project org.apache.karaf.shell.core: Could not resolve dependencies for project org.apache.karaf.shell:org.apache.karaf.shell.core:bundle:4.1.0-SNAPSHOT: Failed to collect dependencies at org.apache.felix:org.apache.felix.gogo.runtime:jar:1.0.1-SNAPSHOT: Failed to read artifact descriptor for org.apache.felix:org.apache.felix.gogo.runtime:jar:1.0.1-SNAPSHOT: Could not find artifact org.apache.felix:gogo-parent:pom:1.0.1-SNAPSHOT in apache-snapshots (http://repository.apache.org/content/groups/snapshots-group) -> [Help 1] {code} We have to disable the karaf quickstart until the upstream has fixed this issue or the 4.1.0 release -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 22:44:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 15 Dec 2016 22:44:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2820) Quickstart build karaf failed due to can not find the org.apache.felix:gogo-parent 1.0.1-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #184 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Quickstart build karaf failed due to can not find the org.apache.felix:gogo-parent 1.0.1-SNAPSHOT > ------------------------------------------------------------------------------------------------- > > Key: JBTM-2820 > URL: https://issues.jboss.org/browse/JBTM-2820 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/26 > {code} > [ERROR] Failed to execute goal on project org.apache.karaf.shell.core: Could not resolve dependencies for project org.apache.karaf.shell:org.apache.karaf.shell.core:bundle:4.1.0-SNAPSHOT: Failed to collect dependencies at org.apache.felix:org.apache.felix.gogo.runtime:jar:1.0.1-SNAPSHOT: Failed to read artifact descriptor for org.apache.felix:org.apache.felix.gogo.runtime:jar:1.0.1-SNAPSHOT: Could not find artifact org.apache.felix:gogo-parent:pom:1.0.1-SNAPSHOT in apache-snapshots (http://repository.apache.org/content/groups/snapshots-group) -> [Help 1] > {code} > We have to disable the karaf quickstart until the upstream has fixed this issue or the 4.1.0 release -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 15 22:45:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 15 Dec 2016 22:45:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339398#comment-13339398 ] RH Bugzilla Integration commented on JBTM-2749: ----------------------------------------------- Miroslav Sochurek changed the Status of [bug 1399703|https://bugzilla.redhat.com/show_bug.cgi?id=1399703] from POST to MODIFIED > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 4.17.37, 5.2.19.Final, 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 01:20:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 16 Dec 2016 01:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339423#comment-13339423 ] RH Bugzilla Integration commented on JBTM-2749: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1399703|https://bugzilla.redhat.com/show_bug.cgi?id=1399703] from MODIFIED to ON_QA > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 4.17.37, 5.2.19.Final, 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 04:35:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 04:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339498#comment-13339498 ] Tom Jenkinson commented on JBTM-2816: ------------------------------------- Is it not mvn.cmd? > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 04:52:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 04:52:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339507#comment-13339507 ] Tom Jenkinson commented on JBTM-2816: ------------------------------------- I have raised https://github.com/jbosstm/quickstart/pull/185 to test this > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 05:02:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Dec 2016 05:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339514#comment-13339514 ] Ondra Chaloupka commented on JBTM-2819: --------------------------------------- I see. Well, this is an issue of test. Nevertheless documenting behavior would be fine :) but you can reject this one. I have to admit that I overlooked the consequences of the participant's heuristic rollback state. Part of the reason was that the JTA implementation works differently [1] - it ends with in heuristic mixed state. May I consider this as different behavior for "jta style" transactions and correct for jta and jts? It seems to me that transaction itself is with type heuristic mixed but the participant is with heuristic rollback. But jta does not save type directly to participant but its state is delivered from transaction type. Am I at lest partly right here? Thank you {code} [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) { "outcome" => "success", "result" => { "expose-all-logs" => false, "type" => "default", "transactions" => {"0:ffff7f000001:9a556c9:5853b579:15" => { "age-in-seconds" => "29", "id" => "0:ffff7f000001:9a556c9:5853b579:15", "jmx-name" => undefined, "type" => "StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA", "participants" => {"java:/TestXAResource-48" => { "eis-product-name" => "Crash Recovery Test", "eis-product-version" => "EAP Test", "jmx-name" => undefined, "jndi-name" => "java:/TestXAResource-48", "status" => "HEURISTIC", "type" => "/StateManager/AbstractRecord/XAResourceRecord" }} }} } } {code} > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 07:01:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 07:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2785) Provide a tooling operation to suspend/resume the recovery manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2785. ---------------------------------- Resolution: Rejected Rejecting since we have not seen this as an issue and there is no test case that would highlight the problem. > Provide a tooling operation to suspend/resume the recovery manager > ------------------------------------------------------------------ > > Key: JBTM-2785 > URL: https://issues.jboss.org/browse/JBTM-2785 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Affects Versions: 5.3.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Some tooling operations update the state of transaction log records and these updates could interfere with what the recovery manager is doing. Tooling updates should pause the recovery manager prior to performing such updates. Since tooling and recovery can run in different JVMs we need an MBean operation to suspend/resume the recovery manager to protect against this scenario. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 07:24:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 07:24:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2821) Improve tooling documentation about clearing heuristics In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2821: -------------------------------------- Summary: Improve tooling documentation about clearing heuristics Key: JBTM-2821 URL: https://issues.jboss.org/browse/JBTM-2821 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Documentation Affects Versions: 5.4.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.next The tooling will only allow heuristics to be cleared if the are of type heuristic mixed or heuristic hazard. This is because for the other types (heuristic rollaback./commit) it is too late to reattempt commit. The documentation should clarify that this is the behaviour of the clearHeuristic operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 07:28:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 07:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2821) Improve tooling documentation about clearing heuristics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #43 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Improve tooling documentation about clearing heuristics > ------------------------------------------------------- > > Key: JBTM-2821 > URL: https://issues.jboss.org/browse/JBTM-2821 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The tooling will only allow heuristics to be cleared if the are of type heuristic mixed or heuristic hazard. This is because for the other types (heuristic rollaback./commit) it is too late to reattempt commit. The documentation should clarify that this is the behaviour of the clearHeuristic operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 07:28:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 07:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #43 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 08:08:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 08:08:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2816: --------------------------------- I had to revert this so I could do a release sorry > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 08:10:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 08:10:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2805) Karaf fails to build in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2805: --------------------------------- I had to revert this so I could do a release sorry > Karaf fails to build in CI > -------------------------- > > Key: JBTM-2805 > URL: https://issues.jboss.org/browse/JBTM-2805 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Amos Feng > > We should try to avoid building Karaf in CI. > At this point it fails to build. > {code} > [INFO] --- maven-resources-plugin:2.7:resources (process-resources) @ apache-karaf-minimal --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 4 resources > [INFO] > [INFO] --- karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) @ apache-karaf-minimal --- > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Apache Karaf ....................................... SUCCESS [ 4.795 s] > [INFO] Apache Karaf :: JAAS ............................... SUCCESS [ 0.017 s] > [INFO] Apache Karaf :: JAAS :: Boot ....................... SUCCESS [ 2.413 s] > [INFO] Apache Karaf :: Util ............................... SUCCESS [ 4.843 s] > [INFO] Apache Karaf :: Main ............................... SUCCESS [ 11.143 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Features :: Extension .............. SUCCESS [ 0.157 s] > [INFO] Apache Karaf :: Service ............................ SUCCESS [ 0.012 s] > [INFO] Apache Karaf :: Service :: Guard ................... SUCCESS [ 8.831 s] > [INFO] Apache Karaf :: Shell .............................. SUCCESS [ 0.010 s] > [INFO] Apache Karaf :: Shell :: Core ...................... SUCCESS [ 6.523 s] > [INFO] Apache Karaf :: Tooling ............................ SUCCESS [ 0.013 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin for Services Metadata SUCCESS [ 58.898 s] > [INFO] Apache Karaf :: Features :: Core ................... SUCCESS [ 5.522 s] > [INFO] Apache Karaf :: Features :: Command ................ SUCCESS [ 0.845 s] > [INFO] Apache Karaf :: KAR :: Core ........................ SUCCESS [ 0.869 s] > [INFO] Apache Karaf :: JAAS :: Config ..................... SUCCESS [ 7.906 s] > [INFO] Apache Karaf :: JAAS :: Modules .................... SUCCESS [ 18.313 s] > [INFO] Apache Karaf :: Bundle ............................. SUCCESS [ 0.009 s] > [INFO] Apache Karaf :: Bundle :: Core ..................... SUCCESS [ 1.076 s] > [INFO] Apache Karaf :: Bundle :: BlueprintStateService .... SUCCESS [ 0.095 s] > [INFO] Apache Karaf :: Bundle :: SpringStateService ....... SUCCESS [ 8.690 s] > [INFO] Apache Karaf :: ConfigAdmin :: Core ................ SUCCESS [ 0.454 s] > [INFO] Apache Karaf :: Tooling :: Utils ................... SUCCESS [ 2.911 s] > [INFO] Apache Karaf :: Deployer ........................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Deployer :: Blueprint .............. SUCCESS [ 2.328 s] > [INFO] Apache Karaf :: Deployer :: Spring ................. SUCCESS [ 0.166 s] > [INFO] Apache Karaf :: Demos :: Profiles :: Registry ...... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Profile :: Core .................... SUCCESS [ 9.123 s] > [INFO] Apache Karaf :: Instance :: Core ................... SUCCESS [ 1.096 s] > [INFO] Apache Karaf :: Package :: Core .................... SUCCESS [ 0.316 s] > [INFO] Apache Karaf :: HTTP :: Core ....................... SUCCESS [ 3.623 s] > [INFO] Apache Karaf :: Service :: Core .................... SUCCESS [ 0.323 s] > [INFO] Apache Karaf :: Log :: Core ........................ SUCCESS [ 4.122 s] > [INFO] Apache Karaf :: Deployer :: Features ............... SUCCESS [ 0.568 s] > [INFO] Apache Karaf :: Deployer :: Karaf Archive (.kar) ... SUCCESS [ 0.491 s] > [INFO] Apache Karaf :: Deployer :: Wrap Non OSGi Jar ...... SUCCESS [ 0.100 s] > [INFO] Apache Karaf :: Shell :: Various Commands .......... SUCCESS [ 0.471 s] > [INFO] Apache Karaf :: Shell :: Console ................... SUCCESS [ 3.362 s] > [INFO] Apache Karaf :: Shell :: Table ..................... SUCCESS [ 0.111 s] > [INFO] Apache Karaf :: Shell :: SSH ....................... SUCCESS [ 2.032 s] > [INFO] Apache Karaf :: JAAS :: Jasypt Encryption .......... SUCCESS [ 2.921 s] > [INFO] Apache Karaf :: JAAS :: Command .................... SUCCESS [ 0.492 s] > [INFO] Apache Karaf :: JAAS :: Blueprint .................. SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Config ........ SUCCESS [ 0.081 s] > [INFO] Apache Karaf :: JAAS :: Blueprint :: Jasypt ........ SUCCESS [ 1.509 s] > [INFO] Apache Karaf :: Client ............................. SUCCESS [ 0.164 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Management ......................... SUCCESS [ 0.212 s] > [INFO] Apache Karaf :: System :: Core ..................... SUCCESS [ 0.329 s] > [INFO] Apache Karaf :: Web :: Core ........................ SUCCESS [ 0.328 s] > [INFO] Apache Karaf :: Wrapper :: Core .................... SUCCESS [ 0.667 s] > [INFO] Apache Karaf :: Web Console ........................ SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Web Console :: Console ............. SUCCESS [ 3.205 s] > [INFO] Apache Karaf :: Web Console :: Features Plugin ..... SUCCESS [ 0.559 s] > [INFO] Apache Karaf :: Web Console :: Gogo Plugin ......... SUCCESS [ 0.617 s] > [INFO] Apache Karaf :: Web Console :: HTTP Plugin ......... SUCCESS [ 0.567 s] > [INFO] Apache Karaf :: Web Console :: Instance Plugin ..... SUCCESS [ 0.224 s] > [INFO] Apache Karaf :: Exception .......................... SUCCESS [ 0.031 s] > [INFO] Apache Karaf :: Scheduler :: Core .................. SUCCESS [ 3.628 s] > [INFO] Apache Karaf :: Declarative Services (DS) .......... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: SCR :: Shell Commands .............. SUCCESS [ 3.391 s] > [INFO] Apache Karaf :: SCR :: Management MBeans ........... SUCCESS [ 1.491 s] > [INFO] Apache Karaf :: SCR :: Bundle State ................ SUCCESS [ 0.176 s] > [INFO] Apache Karaf :: SCR :: Examples .................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: SCR :: Examples :: Basic Service ... SUCCESS [ 0.060 s] > [INFO] Apache Karaf :: SCR :: Examples :: Managed Services SUCCESS [ 0.076 s] > [INFO] Apache Karaf :: SCR :: Examples :: Component Factories SUCCESS [ 0.063 s] > [INFO] Apache Karaf :: Diagnostic ......................... SUCCESS [ 0.007 s] > [INFO] Apache Karaf :: Diagnostic :: Boot ................. SUCCESS [ 0.096 s] > [INFO] Apache Karaf :: Diagnostic :: Core ................. SUCCESS [ 0.748 s] > [INFO] Apache Karaf :: OBR :: Core ........................ SUCCESS [ 1.771 s] > [INFO] Apache Karaf :: JNDI :: Core ....................... SUCCESS [ 1.765 s] > [INFO] Apache Karaf :: JDBC :: Core ....................... SUCCESS [ 0.410 s] > [INFO] Apache Karaf :: JMS :: Core ........................ SUCCESS [ 6.591 s] > [INFO] Apache Karaf :: Features ........................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Parent ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: JPA :: Hibernate ................... SUCCESS [ 8.436 s] > [INFO] Apache Karaf :: OSGi Services :: Coordinator ....... SUCCESS [ 1.763 s] > [INFO] Apache Karaf :: OSGi Services :: EventAdmin ........ SUCCESS [ 1.511 s] > [INFO] Apache Karaf :: OSGi Services :: Static ConfigAdmin SUCCESS [ 0.087 s] > [INFO] Apache Karaf :: OSGi Services ...................... SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Subsystem :: Core .................. SUCCESS [ 5.008 s] > [INFO] Apache Karaf :: OSGi Services :: Event ............. SUCCESS [ 1.709 s] > [INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin ...... SUCCESS [ 7.875 s] > [INFO] Apache Karaf :: Assemblies ......................... SUCCESS [ 0.008 s] > [INFO] Apache Karaf :: Assemblies :: Features ............. SUCCESS [ 0.006 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Base ..... SUCCESS [ 3.828 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Framework SUCCESS [ 2.555 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Static ... SUCCESS [ 1.836 s] > [INFO] Apache Karaf :: Assemblies :: Features :: Standard . SUCCESS [01:12 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Spring ... SUCCESS [01:19 min] > [INFO] Apache Karaf :: Assemblies :: Features :: Enterprise SUCCESS [ 42.574 s] > [INFO] Apache Karaf :: Assemblies :: Demos ................ SUCCESS [ 0.075 s] > [INFO] Apache Karaf :: Assemblies :: Minimal Distribution . FAILURE [ 0.097 s] > [INFO] Apache Karaf :: Assemblies :: Default Distribution . SKIPPED > [INFO] Apache Karaf :: Demos .............................. SKIPPED > [INFO] Apache Karaf :: Demos :: Web ....................... SKIPPED > [INFO] Apache Karaf :: Demos :: Branding :: Shell ......... SKIPPED > [INFO] Apache Karaf :: Demos :: Command :: Extend Console . SKIPPED > [INFO] Apache Karaf :: Demos :: Demo Dump provider ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer .................. SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Kar ........... SKIPPED > [INFO] Apache Karaf :: Demos :: Deployer :: Bundle ........ SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Dynamic Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles :: Static Assembly SKIPPED > [INFO] Apache Karaf :: Demos :: Profiles .................. SKIPPED > [INFO] Apache Karaf :: Archetypes ......................... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Assembly Archetype ... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Command Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Feature Archetype .... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Kar Archetype ........ SKIPPED > [INFO] Apache Karaf :: Archetypes :: Bundle Archetype ..... SKIPPED > [INFO] Apache Karaf :: Archetypes :: Blueprint Archetype .. SKIPPED > [INFO] Apache Karaf :: Integration Tests .................. SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 07:17 min > [INFO] Finished at: 2016-11-29T00:19:34+00:00 > [INFO] Final Memory: 165M/1003M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project apache-karaf-minimal: Unable to parse configuration of mojo org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly for parameter pidsToExtract: Cannot assign configuration entry 'pidsToExtract' with value '!jmx.acl.*, > [ERROR] !org.apache.karaf.command.acl.*, > [ERROR] *' of type java.lang.String to property of type java.util.List > [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/PluginConfigurationException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :apache-karaf-minimal > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:00:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 10:00:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2819: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:01:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 10:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2819: ------------------------------------ Reopening because it needs rejecting and not resolving. > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:20:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 10:20:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339690#comment-13339690 ] Michael Musgrove commented on JBTM-2819: ---------------------------------------- I have clarified the semantics of clearing heuristics in the linked documentation issue. QE are reworking the test to see if there is an issue with our handling of these types of transaction. > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:21:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 10:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2819. ---------------------------------- Resolution: Rejected > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:21:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 10:21:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2821) Improve tooling documentation about clearing heuristics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2821: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Improve tooling documentation about clearing heuristics > ------------------------------------------------------- > > Key: JBTM-2821 > URL: https://issues.jboss.org/browse/JBTM-2821 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The tooling will only allow heuristics to be cleared if the are of type heuristic mixed or heuristic hazard. This is because for the other types (heuristic rollaback./commit) it is too late to reattempt commit. The documentation should clarify that this is the behaviour of the clearHeuristic operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:24:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:24:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2816: -------------------------------- Fix Version/s: (was: 5.next) > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:25:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2809) Include jboss-logging in the QA dependencies so it can be debugged easier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2809. --------------------------------- Resolution: Done > Include jboss-logging in the QA dependencies so it can be debugged easier > ------------------------------------------------------------------------- > > Key: JBTM-2809 > URL: https://issues.jboss.org/browse/JBTM-2809 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Unless jboss-logging is included you can't see tracing on the console when debugging issues -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:25:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:25:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2810) Add a test to show RMERR handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2810. --------------------------------- Resolution: Done > Add a test to show RMERR handling > --------------------------------- > > Key: JBTM-2810 > URL: https://issues.jboss.org/browse/JBTM-2810 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > We had a question about why the log was now left when an XAR throws a HEURB. It was because if the forget fails we now remember the log. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:26:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2813: -------------------------------- Fix Version/s: 5.next > Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2813 > URL: https://issues.jboss.org/browse/JBTM-2813 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip > > > This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it. > That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected. > When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources) > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:26:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2790: -------------------------------- Fix Version/s: 5.next > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:27:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:27:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2807) StoreManager return always the same store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2807: -------------------------------- Fix Version/s: 5.next > StoreManager return always the same store > ----------------------------------------- > > Key: JBTM-2807 > URL: https://issues.jboss.org/browse/JBTM-2807 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ivan Straka > Assignee: Ivan Straka > Fix For: 5.next > > > StoreManager.get*Store() returns always the same store even after changing it via BeanPopulator. > Problem is that StoreManager.actionStore, StoreManager.stateStore, StoreManager.communicationStore won't change after they are set for the first time. > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L53 > this method should null stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2798) Connection.isClosed throws NullPointerException or returns false after close In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2798: -------------------------------- Fix Version/s: 5.next > Connection.isClosed throws NullPointerException or returns false after close > ---------------------------------------------------------------------------- > > Key: JBTM-2798 > URL: https://issues.jboss.org/browse/JBTM-2798 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Mirko Streckenbach > Fix For: 5.next > > > The following snippet fails with a NullPointerException: > {code} > Connection c = ConnectionManager.create(dbUrl, properties); > System.err.println("closed1=" + c.isClosed()); > c.close(); > System.err.println("closed2=" + c.isClosed()); > {code} > output: > {code} > closed1=false > java.lang.NullPointerException > at com.arjuna.ats.internal.jdbc.ConnectionImple.closeImpl(ConnectionImple.java:389) > at com.arjuna.ats.internal.jdbc.ConnectionImple.close(ConnectionImple.java:381) > at org.jboss.narayana.quickstarts.jta.Main.main(Main.java:140) > {code} > If it is modified to "use" the init the physical connect before closing, it will not throw an > exception, but returns false for isClosed after the close: > {code} > Connection c = ConnectionManager.create(dbUrl, properties); > System.err.println("closed1=" + c.isClosed()); > c.createStatement().close(); > System.err.println("closed2=" + c.isClosed()); > c.close(); > System.err.println("closed3=" + c.isClosed()); > {code} > output: > {code} > closed1=false > closed2=false > closed3=false > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:29:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:29:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2782) XTS crash recovery test Byteman rules use wrong variable types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2782: -------------------------------- Fix Version/s: 5.next > XTS crash recovery test Byteman rules use wrong variable types > -------------------------------------------------------------- > > Key: JBTM-2782 > URL: https://issues.jboss.org/browse/JBTM-2782 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > After updating Byteman as part of the compensations recovery work, XTS tests started to fail Byteman type check: > {code} > [INFO] --- byteman-rulecheck-maven-plugin:3.0.6:rulecheck (rulecheck) @ localjunit-crash-recovery-tests --- > [INFO] Checking 11 byteman scripts in /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes > [ERROR] Checking byteman script rules failed with 23 errors > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATCrashDuringCommit.btm line 322 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATHeuristicRecoveryAfterDelayedCommit.btm line 326 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace heuristic committed replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATHeuristicRecoveryAfterDelayedCommit.btm line 346 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringCommit.btm line 543 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringCommit.btm line 564 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringPrepare.btm line 614 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringPrepare.btm line 634 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace coordinator completion complete" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 490 against method complete() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 491 > [ERROR] ERROR : Failed to type check rule "trace participant completion completed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 507 against method completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 508 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion completed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 524 against method completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 525 > [ERROR] ERROR : Failed to type check rule "trace participant completion exit" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 541 against method exit(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 542 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion exit" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 558 against method exit(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 559 > [ERROR] ERROR : Failed to type check rule "trace participant completion close" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 615 against method close() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 616 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion close" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 633 against method close() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 634 > [ERROR] ERROR : Failed to type check rule "trace participant completion closed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 650 against method closed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 651 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion closed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 667 against method closed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 668 > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 685 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommit.btm line 911 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommit.btm line 931 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommitAfterSubordinateExit.btm line 944 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommitAfterSubordinateExit.btm line 963 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringComplete.btm line 1017 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringComplete.btm line 1037 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:30:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2821) Improve tooling documentation about clearing heuristics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2821: -------------------------------- Issue Type: Task (was: Enhancement) > Improve tooling documentation about clearing heuristics > ------------------------------------------------------- > > Key: JBTM-2821 > URL: https://issues.jboss.org/browse/JBTM-2821 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The tooling will only allow heuristics to be cleared if the are of type heuristic mixed or heuristic hazard. This is because for the other types (heuristic rollaback./commit) it is too late to reattempt commit. The documentation should clarify that this is the behaviour of the clearHeuristic operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:35:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:35:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2782) XTS crash recovery test Byteman rules use wrong variable types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2782: -------------------------------- Issue Type: Task (was: Bug) > XTS crash recovery test Byteman rules use wrong variable types > -------------------------------------------------------------- > > Key: JBTM-2782 > URL: https://issues.jboss.org/browse/JBTM-2782 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > After updating Byteman as part of the compensations recovery work, XTS tests started to fail Byteman type check: > {code} > [INFO] --- byteman-rulecheck-maven-plugin:3.0.6:rulecheck (rulecheck) @ localjunit-crash-recovery-tests --- > [INFO] Checking 11 byteman scripts in /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes > [ERROR] Checking byteman script rules failed with 23 errors > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATCrashDuringCommit.btm line 322 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATHeuristicRecoveryAfterDelayedCommit.btm line 326 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace heuristic committed replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATHeuristicRecoveryAfterDelayedCommit.btm line 346 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringCommit.btm line 543 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringCommit.btm line 564 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringPrepare.btm line 614 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringPrepare.btm line 634 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace coordinator completion complete" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 490 against method complete() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 491 > [ERROR] ERROR : Failed to type check rule "trace participant completion completed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 507 against method completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 508 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion completed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 524 against method completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 525 > [ERROR] ERROR : Failed to type check rule "trace participant completion exit" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 541 against method exit(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 542 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion exit" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 558 against method exit(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 559 > [ERROR] ERROR : Failed to type check rule "trace participant completion close" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 615 against method close() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 616 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion close" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 633 against method close() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 634 > [ERROR] ERROR : Failed to type check rule "trace participant completion closed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 650 against method closed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 651 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion closed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 667 against method closed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 668 > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 685 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommit.btm line 911 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommit.btm line 931 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommitAfterSubordinateExit.btm line 944 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommitAfterSubordinateExit.btm line 963 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringComplete.btm line 1017 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringComplete.btm line 1037 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2818: -------------------------------- Issue Type: Task (was: Bug) > Document tooling operation for deleting participants > ---------------------------------------------------- > > Key: JBTM-2818 > URL: https://issues.jboss.org/browse/JBTM-2818 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2790: -------------------------------- Fix Version/s: (was: 5.next) > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 10:38:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 10:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2786) MySQL JDBCStore occasionally gets deadlock exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2786: -------------------------------- Issue Type: Enhancement (was: Bug) > MySQL JDBCStore occasionally gets deadlock exception > ---------------------------------------------------- > > Key: JBTM-2786 > URL: https://issues.jboss.org/browse/JBTM-2786 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Occasionally in QA tests we see the MySQL CI job fail with messages about deadlocks. > From what I can see from http://stackoverflow.com/questions/2332768/how-to-avoid-mysql-deadlock-found-when-trying-to-get-lock-try-restarting-trans it can be because the where clauses are not ordered the same so a table lock can happen. Reordering the where clauses would hopefully fix this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:07:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Dec 2016 11:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2819) Recover operation does not work for participant of JCA type transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13339725#comment-13339725 ] Michael Musgrove commented on JBTM-2819: ---------------------------------------- [~ochaloup] Although I have rejected the issue I have not ignored your question in the above comment. I will provide an update after I have investigated. > Recover operation does not work for participant of JCA type transactions > ------------------------------------------------------------------------ > > Key: JBTM-2819 > URL: https://issues.jboss.org/browse/JBTM-2819 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Attachments: heuristic-rollback-objectstore.zip > > > Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test shows following > {code} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:probe > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-4cecb39b:585109e2:31" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "jmx-name" => undefined, > "type" => "CosTransactions/XAResourceRecord", > "participants" => undefined > }, > "0:ffff7f000001:-4cecb39b:585109e2:28" => { > "age-in-seconds" => "1481798762", > "id" => "0:ffff7f000001:-4cecb39b:585109e2:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > }} > } > } > } > } > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource > { > "outcome" => "success", > "result" => { > "eis-product-name" => "unavailable", > "eis-product-version" => "unavailable", > "jmx-name" => undefined, > "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31", > "status" => "HEURISTIC_ROLLBACK", > "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord" > } > } > {code} > I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point RAR {{XATerminator.commit}} could commit such participant. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2821) Improve tooling documentation about clearing heuristics In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2821. ------------------------------- > Improve tooling documentation about clearing heuristics > ------------------------------------------------------- > > Key: JBTM-2821 > URL: https://issues.jboss.org/browse/JBTM-2821 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.4.1.Final > > > The tooling will only allow heuristics to be cleared if the are of type heuristic mixed or heuristic hazard. This is because for the other types (heuristic rollaback./commit) it is too late to reattempt commit. The documentation should clarify that this is the behaviour of the clearHeuristic operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2818) Document tooling operation for deleting participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2818. ------------------------------- > Document tooling operation for deleting participants > ---------------------------------------------------- > > Key: JBTM-2818 > URL: https://issues.jboss.org/browse/JBTM-2818 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.4.1.Final > > > The operation for deleting participants via the WildFly cli needs adding to our documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2814) Migrate Mark Little's TransactionalVert.x work to narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2814. ------------------------------- > Migrate Mark Little's TransactionalVert.x work to narayana > ---------------------------------------------------------- > > Key: JBTM-2814 > URL: https://issues.jboss.org/browse/JBTM-2814 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: vertx > Affects Versions: 5.4.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.4.1.Final > > > Migrate Mark's TransactionalVert.x repo (https://github.com/nmcl/TransactionalVert.x) to the narayana repo and port to Vert.x 3 in the process. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2811) BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2811. ------------------------------- > BlackTie XATMI session ID lock held during tpgetReply(TPGETANY) so can deadlock when message is received > -------------------------------------------------------------------------------------------------------- > > Key: JBTM-2811 > URL: https://issues.jboss.org/browse/JBTM-2811 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > The lock is obtained before the receive but then the receive doesn't release the lock until after and so if a message is received in the middle tpgetreply is not notified. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2810) Add a test to show RMERR handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2810. ------------------------------- > Add a test to show RMERR handling > --------------------------------- > > Key: JBTM-2810 > URL: https://issues.jboss.org/browse/JBTM-2810 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > We had a question about why the log was now left when an XAR throws a HEURB. It was because if the forget fails we now remember the log. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2809) Include jboss-logging in the QA dependencies so it can be debugged easier In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2809. ------------------------------- > Include jboss-logging in the QA dependencies so it can be debugged easier > ------------------------------------------------------------------------- > > Key: JBTM-2809 > URL: https://issues.jboss.org/browse/JBTM-2809 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > Unless jboss-logging is included you can't see tracing on the console when debugging issues -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2812) Retain a log if a forget call on a resource fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2812. ------------------------------- > Retain a log if a forget call on a resource fails > ------------------------------------------------- > > Key: JBTM-2812 > URL: https://issues.jboss.org/browse/JBTM-2812 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.4.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.4.1.Final > > > When we clear a heuristic from XAResourceRecord we call forget on the resource and then delete the record even if the forget operation fails. The preferred behaviour is to retain the record if the forget fails so that it can be reported via our tooling and so that we still have the option of later retrying the forget operation (also via the tooling). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2813) Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2813. ------------------------------- > Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2813 > URL: https://issues.jboss.org/browse/JBTM-2813 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.4.0.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Fix For: 5.4.1.Final > > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log, tx-object-store_after-prepare.zip, tx-object-store_after-recover.zip > > > This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it. > That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected. > When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources) > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource() > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => { > "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined, > "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined > } > } > } > {code} > I'm adding the content of {{tx-object-store}} at both phases and the {{server.log}} as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2808) Hang in getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2808. ------------------------------- > Hang in getThreadId > ------------------- > > Key: JBTM-2808 > URL: https://issues.jboss.org/browse/JBTM-2808 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.4.1.Final > > > at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341) > - locked <0x000000059f929538> (a java.lang.ref.ReferenceQueue) > at java.util.WeakHashMap.getTable(WeakHashMap.java:350) > at java.util.WeakHashMap.get(WeakHashMap.java:397) > at com.arjuna.ats.arjuna.utils.ThreadUtil.getThreadId(ThreadUtil.java:56) > No other locking, seems WeakHashMap needs synchronized. > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > https://issues.jboss.org/browse/JBRULES-541?_sscc=t -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2807) StoreManager return always the same store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2807. ------------------------------- > StoreManager return always the same store > ----------------------------------------- > > Key: JBTM-2807 > URL: https://issues.jboss.org/browse/JBTM-2807 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Ivan Straka > Assignee: Ivan Straka > Fix For: 5.4.1.Final > > > StoreManager.get*Store() returns always the same store even after changing it via BeanPopulator. > Problem is that StoreManager.actionStore, StoreManager.stateStore, StoreManager.communicationStore won't change after they are set for the first time. > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L53 > this method should null stores. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2804) ObjStoreBrowserTest.java can miss a recovery scan In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2804. ------------------------------- > ObjStoreBrowserTest.java can miss a recovery scan > ------------------------------------------------- > > Key: JBTM-2804 > URL: https://issues.jboss.org/browse/JBTM-2804 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > As the ObjStoreBrowserTest.java uses a socket to ask for recovery from a threaded recovery manager it is possible that the recovery manager is just completing a scan and so the state the test expects will not be satisfied. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2803) compareHierarchies traceln's wrong elements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2803. ------------------------------- > compareHierarchies traceln's wrong elements > ------------------------------------------- > > Key: JBTM-2803 > URL: https://issues.jboss.org/browse/JBTM-2803 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > If compareHierarchies is called (only done in trace iirc) then the right elements are compared but if they are not equal the wrong elements are compared IOOBE are possible. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2801) ObjectStoreTest.java assumes that Uids are returned in order which is not guaranteed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2801. ------------------------------- > ObjectStoreTest.java assumes that Uids are returned in order which is not guaranteed > ------------------------------------------------------------------------------------ > > Key: JBTM-2801 > URL: https://issues.jboss.org/browse/JBTM-2801 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > The object store API does not make guarantees about the order -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2802) AtomicObject3.java hammer test hard to debug In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2802. ------------------------------- > AtomicObject3.java hammer test hard to debug > -------------------------------------------- > > Key: JBTM-2802 > URL: https://issues.jboss.org/browse/JBTM-2802 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > As the test outputs to console with println and has many many threads it is too hard to debug. Use log4j. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2800) Miscellaneous qa suite improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2800. ------------------------------- > Miscellaneous qa suite improvements > ----------------------------------- > > Key: JBTM-2800 > URL: https://issues.jboss.org/browse/JBTM-2800 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > Some of the tests are not easy to debug and during debug you have to constantly move your TaskImpl.properties out of the way so provide a way to get more logging and allow setting options such as remote debugger easier. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2798) Connection.isClosed throws NullPointerException or returns false after close In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2798. ------------------------------- > Connection.isClosed throws NullPointerException or returns false after close > ---------------------------------------------------------------------------- > > Key: JBTM-2798 > URL: https://issues.jboss.org/browse/JBTM-2798 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.4.0.Final > Reporter: Mirko Streckenbach > Fix For: 5.4.1.Final > > > The following snippet fails with a NullPointerException: > {code} > Connection c = ConnectionManager.create(dbUrl, properties); > System.err.println("closed1=" + c.isClosed()); > c.close(); > System.err.println("closed2=" + c.isClosed()); > {code} > output: > {code} > closed1=false > java.lang.NullPointerException > at com.arjuna.ats.internal.jdbc.ConnectionImple.closeImpl(ConnectionImple.java:389) > at com.arjuna.ats.internal.jdbc.ConnectionImple.close(ConnectionImple.java:381) > at org.jboss.narayana.quickstarts.jta.Main.main(Main.java:140) > {code} > If it is modified to "use" the init the physical connect before closing, it will not throw an > exception, but returns false for isClosed after the close: > {code} > Connection c = ConnectionManager.create(dbUrl, properties); > System.err.println("closed1=" + c.isClosed()); > c.createStatement().close(); > System.err.println("closed2=" + c.isClosed()); > c.close(); > System.err.println("closed3=" + c.isClosed()); > {code} > output: > {code} > closed1=false > closed2=false > closed3=false > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2787) TestGroup_txcore_recovery::Recovery_Crash_StateManager_Test004 fails with DB2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2787. ------------------------------- > TestGroup_txcore_recovery::Recovery_Crash_StateManager_Test004 fails with DB2 > ----------------------------------------------------------------------------- > > Key: JBTM-2787 > URL: https://issues.jboss.org/browse/JBTM-2787 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > When DB2 tests are running (this is a very slow configuration for CI) the recovery manager process appears to be interfering with the setup of the test. > Set up of test: > 2016-11-06 16:04:03,172 out: 2016-11-06 16:04:03,172 [main] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:4 could not be transitioned to committed > Recovery manager process: > 2016-11-06 16:04:24,188 out: 2016-11-06 16:04:24,188 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:1 could not be transitioned to committed > 2016-11-06 16:04:24,225 out: 2016-11-06 16:04:24,225 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012016: PersistenceRecord::topLevelCommit - commit_state call failed for 0:ffffac11000a:c397:581f5466:1 > 2016-11-06 16:04:24,225 out: 2016-11-06 16:04:24,225 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012022: PersistenceRecord::topLevelCommit - commit_state error > 2016-11-06 16:04:25,504 out: 2016-11-06 16:04:25,504 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:3 could not be transitioned to committed > 2016-11-06 16:04:25,549 out: 2016-11-06 16:04:25,549 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012016: PersistenceRecord::topLevelCommit - commit_state call failed for 0:ffffac11000a:c397:581f5466:3 > 2016-11-06 16:04:25,549 out: 2016-11-06 16:04:25,549 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012022: PersistenceRecord::topLevelCommit - commit_state error > 2016-11-06 16:04:37,523 out: 2016-11-06 16:04:37,523 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:4 could not be transitioned to committed -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2795) Quickstart can not build the karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2795. ------------------------------- > Quickstart can not build the karaf > ---------------------------------- > > Key: JBTM-2795 > URL: https://issues.jboss.org/browse/JBTM-2795 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.4.1.Final > > > {code} > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:kar (package) on project framework: Execution package of goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:kar failed: An API incompatibility was encountered while executing org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:kar: java.lang.NoSuchMethodError: org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.getReadTimeout()I > {code} > It looks like we need to upgrade the maven and to use the build.bat -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2786) MySQL JDBCStore occasionally gets deadlock exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2786. ------------------------------- > MySQL JDBCStore occasionally gets deadlock exception > ---------------------------------------------------- > > Key: JBTM-2786 > URL: https://issues.jboss.org/browse/JBTM-2786 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.1.Final > > > Occasionally in QA tests we see the MySQL CI job fail with messages about deadlocks. > From what I can see from http://stackoverflow.com/questions/2332768/how-to-avoid-mysql-deadlock-found-when-trying-to-get-lock-try-restarting-trans it can be because the where clauses are not ordered the same so a table lock can happen. Reordering the where clauses would hopefully fix this. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:15:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:15:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2782) XTS crash recovery test Byteman rules use wrong variable types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2782. ------------------------------- > XTS crash recovery test Byteman rules use wrong variable types > -------------------------------------------------------------- > > Key: JBTM-2782 > URL: https://issues.jboss.org/browse/JBTM-2782 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.4.1.Final > > > After updating Byteman as part of the compensations recovery work, XTS tests started to fail Byteman type check: > {code} > [INFO] --- byteman-rulecheck-maven-plugin:3.0.6:rulecheck (rulecheck) @ localjunit-crash-recovery-tests --- > [INFO] Checking 11 byteman scripts in /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes > [ERROR] Checking byteman script rules failed with 23 errors > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATCrashDuringCommit.btm line 322 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATHeuristicRecoveryAfterDelayedCommit.btm line 326 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace heuristic committed replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATHeuristicRecoveryAfterDelayedCommit.btm line 346 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringCommit.btm line 543 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringCommit.btm line 564 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringPrepare.btm line 614 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/ATSubordinateCrashDuringPrepare.btm line 634 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace coordinator completion complete" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 490 against method complete() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 491 > [ERROR] ERROR : Failed to type check rule "trace participant completion completed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 507 against method completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 508 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion completed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 524 against method completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 525 > [ERROR] ERROR : Failed to type check rule "trace participant completion exit" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 541 against method exit(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 542 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion exit" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 558 against method exit(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 559 > [ERROR] ERROR : Failed to type check rule "trace participant completion close" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 615 against method close() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 616 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion close" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 633 against method close() com.arjuna.webservices11.wsba.State > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 634 > [ERROR] ERROR : Failed to type check rule "trace participant completion closed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 650 against method closed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 651 > [ERROR] ERROR : Failed to type check rule "trace coordinator completion closed" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 667 against method closed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void > org.jboss.byteman.rule.exception.TypeException: Variable.typeCheck : unable to derive type for variable engine file /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 668 > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BACrashDuringCommit.btm line 685 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommit.btm line 911 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommit.btm line 931 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommitAfterSubordinateExit.btm line 944 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringCommitAfterSubordinateExit.btm line 963 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringComplete.btm line 1017 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > [ERROR] ERROR : Failed to type check rule "trace subordinate prepared replay" loaded from /home/jenkins/workspace/btny-pulls-narayana-jdk8/PROFILE/MAIN/jdk/jdk8.latest/label/linux/XTS/localjunit/crash-recovery-tests/target/test-classes/scripts/BASubordinateCrashDuringComplete.btm line 1037 against method replayPhase2() void > org.jboss.byteman.rule.exception.TypeException: Binding.typecheck unknown type for binding uid > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 16 11:16:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Dec 2016 11:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2673) ThreadUtil getThreadId(Thread) ignores argument In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2673. ------------------------------- > ThreadUtil getThreadId(Thread) ignores argument > ----------------------------------------------- > > Key: JBTM-2673 > URL: https://issues.jboss.org/browse/JBTM-2673 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.4.1.Final > > > During investigation of https://developer.jboss.org/thread/269784?start=15&tstart=0 it was observed that the ThreadUtil implementation does not use the Thread argument and simply uses a ThreadLocal: > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/utils/ThreadUtil.java#L51 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 06:49:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 19 Dec 2016 06:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2799) Javadoc Tomcat module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1109 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Javadoc Tomcat module > --------------------- > > Key: JBTM-2799 > URL: https://issues.jboss.org/browse/JBTM-2799 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 06:49:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 19 Dec 2016 06:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1109 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 08:35:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Dec 2016 08:35:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2822: ----------------------------------- Summary: Add suppressed exceptions for failures during prepare Key: JBTM-2822 URL: https://issues.jboss.org/browse/JBTM-2822 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson JBTM-2673 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 08:35:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Dec 2016 08:35:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2822: -------------------------------- Fix Version/s: 5.next > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JBTM-2673 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 08:37:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Dec 2016 08:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1110 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JBTM-2673 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 08:39:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Dec 2016 08:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2822: -------------------------------- Issue Type: Enhancement (was: Bug) > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JBTM-2673 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 08:40:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Dec 2016 08:40:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2822: -------------------------------- Description: JBTM-2636 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. (was: JBTM-2673 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions.) > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JBTM-2636 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 11:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Dec 2016 11:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2822: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JBTM-2636 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Dec 19 17:02:00 2016 From: issues at jboss.org (Stephen Fikes (JIRA)) Date: Mon, 19 Dec 2016 17:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2823) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: Stephen Fikes created JBTM-2823: ----------------------------------- Summary: Add suppressed exceptions for failures during prepare Key: JBTM-2823 URL: https://issues.jboss.org/browse/JBTM-2823 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Stephen Fikes Assignee: Tom Jenkinson Fix For: 5.next JBTM-2636 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 02:17:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 20 Dec 2016 02:17:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2816) Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13340513#comment-13340513 ] Amos Feng commented on JBTM-2816: --------------------------------- no problem, it does not need to upgrade the maven now since we disable building the karaf > Quickstart can not find the mvn.bat after upgrade to maven 3.3.9 > ---------------------------------------------------------------- > > Key: JBTM-2816 > URL: https://issues.jboss.org/browse/JBTM-2816 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > > The maven 3.3.9 rename the mvn.bat to mvn -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 09:38:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 20 Dec 2016 09:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2824) Check that the changes for JDK-9 support still build with JDK-8 In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2824: -------------------------------------- Summary: Check that the changes for JDK-9 support still build with JDK-8 Key: JBTM-2824 URL: https://issues.jboss.org/browse/JBTM-2824 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System Affects Versions: 5.later Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later JBTM-2685 is adding support for building with the JDK-9 compiler using branch https://github.com/jbosstm/narayana/tree/jdk9-experimental This JIRA is for reporting when the branch fails to build on JDK-8 (currently it is failing because the build is not producing the jar artefact for org.jboss.narayana.jts:narayana-jts-idlj). See CI job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-9-jdk-8 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 10:05:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Dec 2016 10:05:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2759) Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2759: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done The fix which came from static code analysis tooling were already merged. > Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2759 > URL: https://issues.jboss.org/browse/JBTM-2759 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > _CID-17577_: Bad choice of lock object - Potential lock collisions > at class {{BaseTransactionManagerDelegate}}[9] at method {{findLock}}. > {quote} > string_literal: The string literal "__LOCKS_MAP" is an interned string. > ? interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > ? Instead of using "__LOCKS_MAP" as a lock, create a final field of type Object which is only used as a lock. > {quote} > Explanation at description of JBTM-2758 > [9] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/integration/src/main/java/com/arjuna/ats/jbossatx/BaseTransactionManagerDelegate.java#L350 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 10:06:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Dec 2016 10:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2759) Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2759: ---------------------------------- Fix Version/s: 5.3.5.Final > Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2759 > URL: https://issues.jboss.org/browse/JBTM-2759 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.3.5.Final > > > _CID-17577_: Bad choice of lock object - Potential lock collisions > at class {{BaseTransactionManagerDelegate}}[9] at method {{findLock}}. > {quote} > string_literal: The string literal "__LOCKS_MAP" is an interned string. > ? interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > ? Instead of using "__LOCKS_MAP" as a lock, create a final field of type Object which is only used as a lock. > {quote} > Explanation at description of JBTM-2758 > [9] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/integration/src/main/java/com/arjuna/ats/jbossatx/BaseTransactionManagerDelegate.java#L350 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 10:07:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Dec 2016 10:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2758) Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2758: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2758 > URL: https://issues.jboss.org/browse/JBTM-2758 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > _CID-17581_: Bad choice of lock object - Potential lock collisions > at class `FileProcessId`[6] method `getpid` with error message > {quote} > Interned string as a lock may cause deadlocks or performance problems if a library also uses the interned string as a lock. > ?string_literal: The string literal "0x" is an interned string. > ?interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > ?Instead of using "0x" as a lock, create a final field of type Object which is only used as a lock. > {quote} > See Java examples at Coverity page [7]. The explanation there is that > ? String literals are centrally interned and could also be locked on by a > library, causing you to potentially have deadlocks or lock collisions > with other code. > There are several places [8] on net when searching for `java synchronzation on strings`. > [6] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/FileProcessId.java#L63 > [7] https://ondemand.coverity.com/reference/7.6.1/en/coverity#N5069A > [8] http://www.javalobby.org/java/forums/t96352.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 10:07:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Dec 2016 10:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2758) Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2758: ---------------------------------- Fix Version/s: 5.3.5.Final > Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2758 > URL: https://issues.jboss.org/browse/JBTM-2758 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.3.5.Final > > > _CID-17581_: Bad choice of lock object - Potential lock collisions > at class `FileProcessId`[6] method `getpid` with error message > {quote} > Interned string as a lock may cause deadlocks or performance problems if a library also uses the interned string as a lock. > ?string_literal: The string literal "0x" is an interned string. > ?interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > ?Instead of using "0x" as a lock, create a final field of type Object which is only used as a lock. > {quote} > See Java examples at Coverity page [7]. The explanation there is that > ? String literals are centrally interned and could also be locked on by a > library, causing you to potentially have deadlocks or lock collisions > with other code. > There are several places [8] on net when searching for `java synchronzation on strings`. > [6] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/FileProcessId.java#L63 > [7] https://ondemand.coverity.com/reference/7.6.1/en/coverity#N5069A > [8] http://www.javalobby.org/java/forums/t96352.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 10:47:02 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Dec 2016 10:47:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2270: ---------------------------------- Tester: Daniel Simko (was: Ondra Chaloupka) > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS, Tooling > Reporter: Ondra Chaloupka > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Dec 20 11:39:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Dec 2016 11:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2124) Add orphan detection for JTS interposition mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13340878#comment-13340878 ] Ondra Chaloupka commented on JBTM-2124: --------------------------------------- I hit a case connected with this issue. The trouble described at JBTM-2124 belongs to situation where prepare operation is crashed somewhere in the middle. XAResource has in doubt (saves its state in remote transaction store) but TM does not save any info to its object store. The case I want to mention is a little bit different. The JVM is crashed at time when XAResource saves its state in remote transaction store and in TM to its object store too. The recovery manager starts with processing of recovery. If XA_RETRY is not thrown then the rollback would be called. But XA_RETRY causes that log record is just removed from TM object store. After that the case really gets back to the JBTM-2124. But I think if XA_RETRY/RMFAIL does not cause removal of the TM object store record - it would be just left as it is, next round of recovery would be able to rollback the resource and remove the record (of course if broker starts being available at that time). Agreed with Tom that before this issue (JBTM-2124) is fixed the trouble of handling XA_RETRY on recovery rollback is not relevant to be handled differently. > Add orphan detection for JTS interposition mode > ----------------------------------------------- > > Key: JBTM-2124 > URL: https://issues.jboss.org/browse/JBTM-2124 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery > Affects Versions: 4.17.17 > Reporter: Ondra Chaloupka > Assignee: Gytis Trikleris > Fix For: 5.later > > > Currently orphan detection is supported for JTA, not for JTS. Please, add the suport for JTS as well. > The following scenario for JTS causes that the orphan is left in the transaction log store and the prepared resource could held the lock till the time that it's timeouted on the side of the database/jms. > The program flow is following (test run on EAP 6) > enlisting jms xaresource to transaction > sending msg to queue > enlisting xa test resource > preparing jms xaresource > preparing xa test resource > crash JVM at the end of the test XAResource.prepare() > restart app server and recovery is run > During recovery the jms resource is processed correctly because TM found some info in its jts logs. But such info was not saved for test xa resource. The test xa is not rollback. > More info and discussion could be found at: https://bugzilla.redhat.com/show_bug.cgi?id=1064170 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 21 05:58:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 21 Dec 2016 05:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2825) JTA XAResourceRecord does not record the type of heuristic In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2825: -------------------------------------- Summary: JTA XAResourceRecord does not record the type of heuristic Key: JBTM-2825 URL: https://issues.jboss.org/browse/JBTM-2825 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.5.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next When a JTA XAResource receives a heuristic outcome during commit it does not record the type of heuristic. This information is required by the tooling in order to determine whether it is worthwhile reattempting the commit (for mixed and hazard heuristics it is worthwhile). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 21 06:20:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 21 Dec 2016 06:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2825) JTA XAResourceRecord does not record the type of heuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1112 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JTA XAResourceRecord does not record the type of heuristic > ---------------------------------------------------------- > > Key: JBTM-2825 > URL: https://issues.jboss.org/browse/JBTM-2825 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When a JTA XAResource receives a heuristic outcome during commit it does not record the type of heuristic. This information is required by the tooling in order to determine whether it is worthwhile reattempting the commit (for mixed and hazard heuristics it is worthwhile). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 21 10:09:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 21 Dec 2016 10:09:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2825) JTA XAResourceRecord does not record the type of heuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2825: ----------------------------------- Issue Type: Enhancement (was: Bug) > JTA XAResourceRecord does not record the type of heuristic > ---------------------------------------------------------- > > Key: JBTM-2825 > URL: https://issues.jboss.org/browse/JBTM-2825 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When a JTA XAResource receives a heuristic outcome during commit it does not record the type of heuristic. This information is required by the tooling in order to determine whether it is worthwhile reattempting the commit (for mixed and hazard heuristics it is worthwhile). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 21 10:09:00 2016 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 21 Dec 2016 10:09:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2826) JBoss Transactions SPI is missing TwoPhaseOutcome constants In-Reply-To: References: Message-ID: David Lloyd created JBTM-2826: --------------------------------- Summary: JBoss Transactions SPI is missing TwoPhaseOutcome constants Key: JBTM-2826 URL: https://issues.jboss.org/browse/JBTM-2826 Project: JBoss Transaction Manager Issue Type: Bug Components: Application Server Integration Reporter: David Lloyd Assignee: Amos Feng Priority: Minor The jboss-transaction-spi allows applications to be decoupled from Narayana's implementation details, however the {{ImportedTransaction#doPrepare}} method returns an integer that is defined by constants in a class inside of {{com.arjuna.ats.arjuna.coordinator}}. These constants should be copied into the SPI. The workaround is to copy the constant values. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Dec 21 15:27:00 2016 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 21 Dec 2016 15:27:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2827) No easy way to acquire node name from JBoss Transaction SPI In-Reply-To: References: Message-ID: David Lloyd created JBTM-2827: --------------------------------- Summary: No easy way to acquire node name from JBoss Transaction SPI Key: JBTM-2827 URL: https://issues.jboss.org/browse/JBTM-2827 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Application Server Integration Reporter: David Lloyd Assignee: Amos Feng Priority: Minor There's no good way to get the node identifier string for the local transaction environment using the integration SPIs. I have to use {{com.arjuna.ats.arjuna.common.CoreEnvironmentBean#getNodeIdentifier}} which brings in narayana-jta to make this work. It would be nice if this could be gotten from the TransactionManager or perhaps the ExtendedJBossXATerminator. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 22 12:22:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 22 Dec 2016 12:22:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2822) Add suppressed exceptions for failures during prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2822: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1406552 Bugzilla Update: Perform > Add suppressed exceptions for failures during prepare > ----------------------------------------------------- > > Key: JBTM-2822 > URL: https://issues.jboss.org/browse/JBTM-2822 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JBTM-2636 added support for adding suppressed exceptions for issues reported during commit. It would be useful to do the same for prepare exceptions. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 22 14:55:00 2016 From: issues at jboss.org (Brad Maxwell (JIRA)) Date: Thu, 22 Dec 2016 14:55:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2828) [GSS](7.0.z) Upgrade JBoss Transaction Manager to 5.5.1 In-Reply-To: References: Message-ID: Brad Maxwell created JBTM-2828: ---------------------------------- Summary: [GSS](7.0.z) Upgrade JBoss Transaction Manager to 5.5.1 Key: JBTM-2828 URL: https://issues.jboss.org/browse/JBTM-2828 Project: JBoss Transaction Manager Issue Type: Component Upgrade Components: Build System Reporter: Brad Maxwell -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 22 15:48:00 2016 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 22 Dec 2016 15:48:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13341710#comment-13341710 ] Mark Little commented on JBTM-2725: ----------------------------------- Did anyone bother checking the history of the code to determine why we threw the rollback exception? It wasn't always the case and changing it without understanding the reasons is risky. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.5.Final > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 03:38:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 23 Dec 2016 03:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2829) Avoid null pointer exception when comparing JDBC connections In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2829: ------------------------------------- Summary: Avoid null pointer exception when comparing JDBC connections Key: JBTM-2829 URL: https://issues.jboss.org/browse/JBTM-2829 Project: JBoss Transaction Manager Issue Type: Bug Components: Transactional Driver Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Spring Boot extension for the transactional driver doesn't know database URL and uses provided XADataSource to create connection. However, ConnectionImpl expects URL, username and password to not be null https://github.com/jbosstm/narayana/blob/5.5.0.Final/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java#L91. As a result NullPointerException is thrown if connection is reused. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 03:38:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 23 Dec 2016 03:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2829) Avoid null pointer exception when comparing JDBC connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2829 started by Gytis Trikleris. --------------------------------------------- > Avoid null pointer exception when comparing JDBC connections > ------------------------------------------------------------ > > Key: JBTM-2829 > URL: https://issues.jboss.org/browse/JBTM-2829 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring Boot extension for the transactional driver doesn't know database URL and uses provided XADataSource to create connection. However, ConnectionImpl expects URL, username and password to not be null https://github.com/jbosstm/narayana/blob/5.5.0.Final/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java#L91. As a result NullPointerException is thrown if connection is reused. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 03:54:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 23 Dec 2016 03:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2829) Avoid null pointer exception when comparing JDBC connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1114 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Avoid null pointer exception when comparing JDBC connections > ------------------------------------------------------------ > > Key: JBTM-2829 > URL: https://issues.jboss.org/browse/JBTM-2829 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring Boot extension for the transactional driver doesn't know database URL and uses provided XADataSource to create connection. However, ConnectionImpl expects URL, username and password to not be null https://github.com/jbosstm/narayana/blob/5.5.0.Final/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java#L91. As a result NullPointerException is thrown if connection is reused. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 06:19:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 23 Dec 2016 06:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2830) Consider possible compensations framework architecture improvements In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2830: ------------------------------------- Summary: Consider possible compensations framework architecture improvements Key: JBTM-2830 URL: https://issues.jboss.org/browse/JBTM-2830 Project: JBoss Transaction Manager Issue Type: Task Components: Compensations Reporter: Gytis Trikleris Assignee: Tom Jenkinson I've created a document with a list of possible compensations framework improvements. I'm attaching a link to the google doc for you to review and schedule work once appropriate. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 06:40:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 23 Dec 2016 06:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2831: ------------------------------------- Summary: Fix RTS inbound bridge participant deserialiser registration Key: JBTM-2831 URL: https://issues.jboss.org/browse/JBTM-2831 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 10:33:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 23 Dec 2016 10:33:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2829) Avoid null pointer exception when comparing JDBC connections In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2829: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Avoid null pointer exception when comparing JDBC connections > ------------------------------------------------------------ > > Key: JBTM-2829 > URL: https://issues.jboss.org/browse/JBTM-2829 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring Boot extension for the transactional driver doesn't know database URL and uses provided XADataSource to create connection. However, ConnectionImpl expects URL, username and password to not be null https://github.com/jbosstm/narayana/blob/5.5.0.Final/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java#L91. As a result NullPointerException is thrown if connection is reused. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Dec 23 11:29:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 23 Dec 2016 11:29:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2825) JTA XAResourceRecord does not record the type of heuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2825: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JTA XAResourceRecord does not record the type of heuristic > ---------------------------------------------------------- > > Key: JBTM-2825 > URL: https://issues.jboss.org/browse/JBTM-2825 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When a JTA XAResource receives a heuristic outcome during commit it does not record the type of heuristic. This information is required by the tooling in order to determine whether it is worthwhile reattempting the commit (for mixed and hazard heuristics it is worthwhile). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Dec 29 20:16:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 29 Dec 2016 20:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2832) Blacktie TestTPGetRely::test_tpgetrply_with_TPGETANY fail In-Reply-To: References: Message-ID: Amos Feng created JBTM-2832: ------------------------------- Summary: Blacktie TestTPGetRely::test_tpgetrply_with_TPGETANY fail Key: JBTM-2832 URL: https://issues.jboss.org/browse/JBTM-2832 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Priority: Minor [exec] 1) test: TestTPGetRply::test_tpgetrply_with_TPGETANY (F) line: 272 C:\hudson\workspace\narayana-catelyn\blacktie\xatmi\src\test\cpp\TestTPGetRply.cxx [exec] assertion failed [exec] - Expression: _w12pq_u [exec] -- This message was sent by Atlassian JIRA (v7.2.3#72005)