From issues at jboss.org Mon Mar 4 10:35:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Mon, 4 Mar 2019 10:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-3104: -------------------------------------- Assignee: Ondra Chaloupka (was: Michael Musgrove) > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 4 10:37:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Mon, 4 Mar 2019 10:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703342#comment-13703342 ] Michael Musgrove commented on JBTM-3104: ---------------------------------------- [~ochaloup] I am reassigning to you since you understand how the set of profiles in the lra-test module interact with each other. Note also that I had to disable running the TCK by default (see JBTM-3115). > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 4 10:38:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Mon, 4 Mar 2019 10:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Make not running the LRA TCK testing the default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703344#comment-13703344 ] Michael Musgrove commented on JBTM-3115: ---------------------------------------- The precise error when the TCK is run is: > org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/classes/org/eclipse/microprofile/lra/tck/participant/api/LraController.c > Make not running the LRA TCK testing the default > ------------------------------------------------ > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we do not run the TCK by default by setting skipTests to true in the TCK pom -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 4 10:39:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Mon, 4 Mar 2019 10:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703342#comment-13703342 ] Michael Musgrove edited comment on JBTM-3104 at 3/4/19 10:38 AM: ----------------------------------------------------------------- [~ochaloup] I am reassigning to you since you understand how the set of profiles in the lra-test module interact with each other. Note also that I had to disable running the TCK by default (see JBTM-3115). But do let me know if you disagree and I will take another look. was (Author: mmusgrov): [~ochaloup] I am reassigning to you since you understand how the set of profiles in the lra-test module interact with each other. Note also that I had to disable running the TCK by default (see JBTM-3115). > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:08:01 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:08:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3065) Check that starting LRA's via CDI and API in the same method works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3065: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Check that starting LRA's via CDI and API in the same method works > ------------------------------------------------------------------ > > Key: JBTM-3065 > URL: https://issues.jboss.org/browse/JBTM-3065 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The LRA spec supports starting LRA's via a Java API or via Java annotations. If the two approaches are used together in the same resource method then the LRA started via the API should be nested inside the one started by an annotation. > If the annotated class also contains @Compensate and @Complete annotations (which means that the resource should join the outer LRA) and the resource method Joins the nested LRA then the resource should receive callbacks for both the outer and nested LRA's. > The following code shows an example: > {code} > @PUT > @LRA(LRA.Type.REQUIRES_NEW) // starts a new LRA on entry > public String doInTransaction() { > URL lraId = lraClient.startLRA(...); // starts a nested LRA > lraClient.join(...) // join the nested LRA > lraClient.closeLRA(lraId); // close the nested LRA > // assert that the nested callbacks were invoked > // assert that the callbacks for the outer LRA have not been called yet > } > {code} > Similar comments apply if the resource joins via the LRAManagement API: > {code} > @Inject > private LRAManagement lraManagement; > public String doInTransaction() { > lraManagement.joinLRA(this, lraId, 0L, TimeUnit.SECONDS); > // etc > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:09:02 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:09:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3065) Check that starting LRA's via CDI and API in the same method works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703917#comment-13703917 ] Michael Musgrove commented on JBTM-3065: ---------------------------------------- Moved fix version to 5.later since the LRA java API will not be available in the initial release > Check that starting LRA's via CDI and API in the same method works > ------------------------------------------------------------------ > > Key: JBTM-3065 > URL: https://issues.jboss.org/browse/JBTM-3065 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The LRA spec supports starting LRA's via a Java API or via Java annotations. If the two approaches are used together in the same resource method then the LRA started via the API should be nested inside the one started by an annotation. > If the annotated class also contains @Compensate and @Complete annotations (which means that the resource should join the outer LRA) and the resource method Joins the nested LRA then the resource should receive callbacks for both the outer and nested LRA's. > The following code shows an example: > {code} > @PUT > @LRA(LRA.Type.REQUIRES_NEW) // starts a new LRA on entry > public String doInTransaction() { > URL lraId = lraClient.startLRA(...); // starts a nested LRA > lraClient.join(...) // join the nested LRA > lraClient.closeLRA(lraId); // close the nested LRA > // assert that the nested callbacks were invoked > // assert that the callbacks for the outer LRA have not been called yet > } > {code} > Similar comments apply if the resource joins via the LRAManagement API: > {code} > @Inject > private LRAManagement lraManagement; > public String doInTransaction() { > lraManagement.joinLRA(this, lraId, 0L, TimeUnit.SECONDS); > // etc > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:10:01 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:10:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3042) API to get detailed LRA information should not include stats type data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3042: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > API to get detailed LRA information should not include stats type data > ---------------------------------------------------------------------- > > Key: JBTM-3042 > URL: https://issues.jboss.org/browse/JBTM-3042 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The interface to obtain information about an LRA [1] includes data such as when the LRA was started and ended. This type of information is more appropriate to monitoring and statistics gathering rather than core LRA info. Not all implementations may want to / be able to report these accurately so perhaps move them to an extended optional interface > [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-client/src/main/java/io/narayana/lra/client/LRAInfoImpl.java#L90 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:10:02 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:10:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3042) API to get detailed LRA information should not include stats type data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703918#comment-13703918 ] Michael Musgrove commented on JBTM-3042: ---------------------------------------- Moved fix version to 5.later since the LRA java API will not be available in the initial release > API to get detailed LRA information should not include stats type data > ---------------------------------------------------------------------- > > Key: JBTM-3042 > URL: https://issues.jboss.org/browse/JBTM-3042 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The interface to obtain information about an LRA [1] includes data such as when the LRA was started and ended. This type of information is more appropriate to monitoring and statistics gathering rather than core LRA info. Not all implementations may want to / be able to report these accurately so perhaps move them to an extended optional interface > [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-client/src/main/java/io/narayana/lra/client/LRAInfoImpl.java#L90 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:11:05 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:11:05 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703924#comment-13703924 ] Michael Musgrove commented on JBTM-3114: ---------------------------------------- Note that this issue should also apply to the quickstart and conference repos. My recommendation is to disable those until the API is stabilised. > LRA module should depend on a specific snapshot build > ----------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:25:03 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:25:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3116) Temporarily disable LRA quickstarts until the MP LRA spec is more stable In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3116: -------------------------------------- Summary: Temporarily disable LRA quickstarts until the MP LRA spec is more stable Key: JBTM-3116 URL: https://issues.jboss.org/browse/JBTM-3116 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator, LRA Affects Versions: 5.9.3.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The MP LRA draft spec has recently undergone a lot of churn and we need to bring both the narayana implementation and the quickstarts into line with those changes. While that work is being undertaken the quickstarts should be disabled so that users and CI do not use non-working examples. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 09:29:01 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 09:29:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3116) Temporarily disable LRA quickstarts until the MP LRA spec is more stable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #246 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Temporarily disable LRA quickstarts until the MP LRA spec is more stable > ------------------------------------------------------------------------ > > Key: JBTM-3116 > URL: https://issues.jboss.org/browse/JBTM-3116 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The MP LRA draft spec has recently undergone a lot of churn and we need to bring both the narayana implementation and the quickstarts into line with those changes. While that work is being undertaken the quickstarts should be disabled so that users and CI do not use non-working examples. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 11:34:01 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 11:34:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3086) dependentLRA test failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3086: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > dependentLRA test failure > ------------------------- > > Key: JBTM-3086 > URL: https://issues.jboss.org/browse/JBTM-3086 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckTests.java#L461] in the microprofile-lra test suite fails if the [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/annotation/LRA.java#L176] is set to true. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 11:35:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 5 Mar 2019 11:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3086) dependentLRA test failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13704070#comment-13704070 ] Michael Musgrove commented on JBTM-3086: ---------------------------------------- Moved to 5.later since the LRA Java API will not be available in the initial release. > dependentLRA test failure > ------------------------- > > Key: JBTM-3086 > URL: https://issues.jboss.org/browse/JBTM-3086 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckTests.java#L461] in the microprofile-lra test suite fails if the [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/annotation/LRA.java#L176] is set to true. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 5 21:25:00 2019 From: issues at jboss.org (Amos Feng (Jira)) Date: Tue, 5 Mar 2019 21:25:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3057) build javadoc failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-3057: ---------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > build javadoc failure > --------------------- > > Key: JBTM-3057 > URL: https://issues.jboss.org/browse/JBTM-3057 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Major > Fix For: 5.next > > > I have to disable the maven-javadoc-plugin on the JDK9 and it needs more investigation. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 6 05:21:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 6 Mar 2019 05:21:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13704350#comment-13704350 ] Ondra Chaloupka commented on JBTM-3104: --------------------------------------- No problem. I will take a look at this, hopefully this week. > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 6 08:24:03 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Wed, 6 Mar 2019 08:24:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3117) Upgrade to the latest LRA spec version In-Reply-To: References: Message-ID: Martin Stefanko created JBTM-3117: ------------------------------------- Summary: Upgrade to the latest LRA spec version Key: JBTM-3117 URL: https://issues.jboss.org/browse/JBTM-3117 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.9.3.Final Reporter: Martin Stefanko Assignee: Martin Stefanko Upgrade to the latest LRA API and TCK snapshots: ``` 1.0-20190306.071209-294 1.0-20190306.071211-294 ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 6 08:28:02 2019 From: issues at jboss.org (Anonymous (Jira)) Date: Wed, 6 Mar 2019 08:28:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3117) Upgrade to the latest LRA spec version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Martin Stefanko created pull request #1419 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade to the latest LRA spec version > -------------------------------------- > > Key: JBTM-3117 > URL: https://issues.jboss.org/browse/JBTM-3117 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > Upgrade to the latest LRA API and TCK snapshots: > ``` > 1.0-20190306.071209-294 > 1.0-20190306.071211-294 > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 7 08:27:04 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 7 Mar 2019 08:27:04 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3106) Firing an @Initialized(TransactionScoped.class) event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #80 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Firing an @Initialized(TransactionScoped.class) event > ----------------------------------------------------- > > Key: JBTM-3106 > URL: https://issues.jboss.org/browse/JBTM-3106 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Laird Nelson > Priority: Major > > It would be beneficial to have the CDI-specific wrapper around Narayana's TransactionManagerImple that fires an @Initialized(TransactionScoped.class)-qualified event. > For the CDI, it's a good practice. The all built-in scopes have to provide this behaviour. > > The CDI specification says (in section 6.7): > {quote} > Portable extensions are encouraged to synchronously fire: > * an event with qualifier @Initialized(X.class) when a custom context is initialized, i.e. ready for use, > * an event with qualifier @BeforeDestroyed(X.class) when a custom context is about to be destroyed, i.e. before the actual destruction, > * an event with qualifier @Destroyed(X.class) when a custom context is destroyed, i.e. after the actual destruction, > where X is the scope type associated with the context. > A suitable event payload should be chosen. > {quote} > > The {{begin()}} method a Narayana-supplied but CDI-specific transaction manager wrapping Narayana's "ordinary" one should do: > {code} > @Inject > @Initialized(TransactionScoped.class) > private Event initializationBroadcaster; > @Inject @BeforeDestroyed(TransactionScoped.class) > private Event beforeDestructionBroadcaster; > @Inject @Destroyed(TransactionScoped.class) > private Event destructionBroadcaster; > // in its begin() method: > super.begin(); > initializationBroadcaster.fire(this.getTransaction()); > // in its commit() and rollback() methods and anywhere else I'm forgetting: > beforeDestructionBroadcaster.fire(this.getTransaction()); > super.commit(); // or rollback or whatever > destructionBroadcaster.fire(this); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 8 03:57:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Fri, 8 Mar 2019 03:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1420 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 8 04:57:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Fri, 8 Mar 2019 04:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3104: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1420 > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 8 14:29:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Fri, 8 Mar 2019 14:29:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: Lance Ball created JBTM-3118: -------------------------------- Summary: Protocol family unavailable error in lra-coordinator Docker container Key: JBTM-3118 URL: https://issues.jboss.org/browse/JBTM-3118 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.3.Final Reporter: Lance Ball Assignee: Michael Musgrove Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. ```sh docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash ``` Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. ```log 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: java.net.SocketException: Protocol family unavailable at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:433) at sun.nio.ch.Net.bind(Net.java:425) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) ... 5 more 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "undertow"), ("server" => "default-server"), ("http-listener" => "default") ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. Caused by: java.net.SocketException: Protocol family unavailable"}} ``` I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. ```sh java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 8 14:31:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Fri, 8 Mar 2019 14:31:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13705898#comment-13705898 ] Lance Ball commented on JBTM-3118: ---------------------------------- This is a duplicate of a GitHub issue I opened [here][https://github.com/jboss-dockerfiles/narayana/issues/7]. It seems perhaps issues are not tracked there. Maybe consider turning them off in the GitHub preferences and adding a link to the Jira here? > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Michael Musgrove > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 04:24:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 04:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3104: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 05:26:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 05:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3119) Enhance Narayana README with information about tests In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3119: ------------------------------------- Summary: Enhance Narayana README with information about tests Key: JBTM-3119 URL: https://issues.jboss.org/browse/JBTM-3119 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Documentation Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The Narayana `README.md` should contain at least few words about type of tests in the Narayana repository. Any newcomer is confused. See https://github.com/jbosstm/narayana/pull/1403#issuecomment-471367319 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 05:38:02 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 05:38:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3119) Enhance Narayana README with information about tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1421 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Enhance Narayana README with information about tests > ---------------------------------------------------- > > Key: JBTM-3119 > URL: https://issues.jboss.org/browse/JBTM-3119 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The Narayana `README.md` should contain at least few words about type of tests in the Narayana repository. Any newcomer is confused. See https://github.com/jbosstm/narayana/pull/1403#issuecomment-471367319 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 06:28:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 06:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706338#comment-13706338 ] Ondra Chaloupka commented on JBTM-3118: --------------------------------------- [~tomjenkinson] please, to clarify the https://github.com/jbosstm/jboss-dockerfiles) should be deprecated, we will move changes from `jbosstm/jboss-dockerfiles` to `jboss-dockerfiles/narayana` and our release script should start use the https://github.com/jboss-dockerfiles/narayana, correct? > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Michael Musgrove > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 06:44:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 06:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3119) Enhance Narayana README with information about tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3119: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Enhance Narayana README with information about tests > ---------------------------------------------------- > > Key: JBTM-3119 > URL: https://issues.jboss.org/browse/JBTM-3119 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The Narayana `README.md` should contain at least few words about type of tests in the Narayana repository. Any newcomer is confused. See https://github.com/jbosstm/narayana/pull/1403#issuecomment-471367319 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 09:38:04 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 09:38:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3120) Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3120: ------------------------------------- Summary: Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside Key: JBTM-3120 URL: https://issues.jboss.org/browse/JBTM-3120 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka We currently administrate repository https://github.com/jbosstm/jboss-dockerfiles which is out of the date from what is in the jboss generally used https://github.com/jboss-dockerfiles/narayana repository. We should use the `jboss-dockerfiles/narayana` as it's used by all other projects under JBoss umbrella. Steps . retire the https://github.com/jbosstm/jboss-dockerfiles . move changes done in the `jbosstm/jboss-dockerfiles` to `jboss-dockerfiles/narayana` . verify if base image used in the LRA coordinator follows those used by other `jboss-dockerfiles` projects -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 09:44:04 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 09:44:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-3118: ------------------------------------- Assignee: Ondra Chaloupka (was: Michael Musgrove) > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 09:57:01 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 11 Mar 2019 09:57:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3121) Create Quarkus LRA extension In-Reply-To: References: Message-ID: Martin Stefanko created JBTM-3121: ------------------------------------- Summary: Create Quarkus LRA extension Key: JBTM-3121 URL: https://issues.jboss.org/browse/JBTM-3121 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.9.3.Final Reporter: Martin Stefanko Assignee: Martin Stefanko Quarkus LRA extension would significantly help propagate LRA even before release. It doesn't necessarily needs to be included in the quarkus extension list until we have a stable spec version. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 10:34:04 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 10:34:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3120) Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #3 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside > ------------------------------------------------------------------------------------------- > > Key: JBTM-3120 > URL: https://issues.jboss.org/browse/JBTM-3120 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > We currently administrate repository https://github.com/jbosstm/jboss-dockerfiles which is out of the date from what is in the jboss generally used https://github.com/jboss-dockerfiles/narayana repository. > We should use the `jboss-dockerfiles/narayana` as it's used by all other projects under JBoss umbrella. > Steps > . retire the https://github.com/jbosstm/jboss-dockerfiles > . move changes done in the `jbosstm/jboss-dockerfiles` to `jboss-dockerfiles/narayana` > . verify if base image used in the LRA coordinator follows those used by other `jboss-dockerfiles` projects -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 11:40:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 11 Mar 2019 11:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706648#comment-13706648 ] Ondra Chaloupka commented on JBTM-3118: --------------------------------------- [~goldmann] I would like ask you for guidance in one point. For the Narayana LRA we dockefile we have used base image [`redhat-openjdk-18/openjdk18-openshift`|https://github.com/jboss-dockerfiles/narayana/blob/master/lra/lra-coordinator/Dockerfile]. The WFLY uses the [`jboss/base-jdk`|https://github.com/jboss-dockerfiles/wildfly/blob/master/Dockerfile]. Do I understand correctly that `jboss/base-jdk` should be used in general? [~lanceball] may I check with you why do you the command `docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash` and not something like `docker run --rm -p 8080:8080 jbosstm/lra-coordinator`? Do I understand that was because that way the coordinator was started at all? I would like just understand what is needed to do. Thanks a lot! > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 11:48:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Mon, 11 Mar 2019 11:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706657#comment-13706657 ] Lance Ball commented on JBTM-3118: ---------------------------------- [~ochaloup] when I run {{docker run --rm -p 8080:8080 jbosstm/lra-coordinator}}, the container starts but the lra-coordinator fails to start on this line https://github.com/jboss-dockerfiles/narayana/blob/master/lra/lra-coordinator/Dockerfile#L30. To debug what was going on, I used the command {{docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash}} which runs the container, but provides a terminal prompt on the container which allows me to {{cd /deployments}} and run the startup command for the lra-coordinator manually. When I do that, I see the error initially reported. In order to test my work, I start the lra-coordinator by adding the IPv4 flags to the {{java -jar}} command. I think you need to add those flags to the Dockerfile. > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 11 11:49:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Mon, 11 Mar 2019 11:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706657#comment-13706657 ] Lance Ball edited comment on JBTM-3118 at 3/11/19 11:48 AM: ------------------------------------------------------------ [~ochaloup] when I run `{{docker run --rm -p 8080:8080 jbosstm/lra-coordinator}}`, the container starts but the lra-coordinator fails to start on this line https://github.com/jboss-dockerfiles/narayana/blob/master/lra/lra-coordinator/Dockerfile#L30. To debug what was going on, I used the command `{{docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash}}` which runs the container, but provides a terminal prompt on the container which allows me to `{{cd /deployments}}` and run the startup command for the lra-coordinator manually. When I do that, I see the error initially reported. In order to test my work, I start the lra-coordinator by adding the IPv4 flags to the {{java -jar}} command. I think you need to add those flags to the Dockerfile. was (Author: lanceball): [~ochaloup] when I run {{docker run --rm -p 8080:8080 jbosstm/lra-coordinator}}, the container starts but the lra-coordinator fails to start on this line https://github.com/jboss-dockerfiles/narayana/blob/master/lra/lra-coordinator/Dockerfile#L30. To debug what was going on, I used the command {{docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash}} which runs the container, but provides a terminal prompt on the container which allows me to {{cd /deployments}} and run the startup command for the lra-coordinator manually. When I do that, I see the error initially reported. In order to test my work, I start the lra-coordinator by adding the IPv4 flags to the {{java -jar}} command. I think you need to add those flags to the Dockerfile. > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 13 06:45:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Mar 2019 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3122) jbosstm/quickstars can't be run with jdk9+ In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3122: ------------------------------------- Summary: jbosstm/quickstars can't be run with jdk9+ Key: JBTM-3122 URL: https://issues.jboss.org/browse/JBTM-3122 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System Affects Versions: 5.9.3.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the `arquillian.xml`. See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 {code} --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-modules=java.se {code} The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 13 06:46:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Mar 2019 06:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3122: ---------------------------------- Summary: jbosstm/quickstarts tests can't be run with jdk9+ (was: jbosstm/quickstars can't be run with jdk9+) > jbosstm/quickstarts tests can't be run with jdk9+ > ------------------------------------------------- > > Key: JBTM-3122 > URL: https://issues.jboss.org/browse/JBTM-3122 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). > The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the `arquillian.xml`. > See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 > {code} > --add-exports=java.base/sun.nio.ch=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED > --add-modules=java.se > {code} > The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. > Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 13 06:46:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Mar 2019 06:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3122: ---------------------------------- Description: Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}. See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 {code} --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-modules=java.se {code} The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. was: Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the `arquillian.xml`. See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 {code} --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-modules=java.se {code} The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. > jbosstm/quickstarts tests can't be run with jdk9+ > ------------------------------------------------- > > Key: JBTM-3122 > URL: https://issues.jboss.org/browse/JBTM-3122 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). > The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}. > See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 > {code} > --add-exports=java.base/sun.nio.ch=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED > --add-modules=java.se > {code} > The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. > Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 13 10:50:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Mar 2019 10:50:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707871#comment-13707871 ] Ondra Chaloupka commented on JBTM-3118: --------------------------------------- [~goldmann][~lanceball] thank you for your remarks. I will fix the lra dockerfile following your suggestions. > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 13 11:37:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Wed, 13 Mar 2019 11:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707912#comment-13707912 ] Lance Ball commented on JBTM-3118: ---------------------------------- [~ochaloup] if it helps at all, [here|https://gist.github.com/lance/47c686634b073d8495e4ad58fe69d261] are the changes I have made locally to test the [work I am doing|https://github.com/lance/crockpot] in Node.js. > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 14 09:02:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 14 Mar 2019 09:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3118: ---------------------------------- Git Pull Request: https://github.com/jboss-dockerfiles/narayana/pull/8 > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 14 09:03:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 14 Mar 2019 09:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708345#comment-13708345 ] Ondra Chaloupka commented on JBTM-3118: --------------------------------------- [~lanceball] thanks. I adjusted your changes and created PR https://github.com/jboss-dockerfiles/narayana/pull/8 > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 14 10:22:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Thu, 14 Mar 2019 10:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3117) Upgrade to the latest LRA spec version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708390#comment-13708390 ] Michael Musgrove commented on JBTM-3117: ---------------------------------------- The next upgrade is to the following versions: {quote} 1.0-20190313.061211-301 1.0-20190313.061212-301 {quote} > Upgrade to the latest LRA spec version > -------------------------------------- > > Key: JBTM-3117 > URL: https://issues.jboss.org/browse/JBTM-3117 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > Upgrade to the latest LRA API and TCK snapshots: > ``` > 1.0-20190306.071209-294 > 1.0-20190306.071211-294 > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 14 12:29:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 14 Mar 2019 12:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3118: ---------------------------------- Status: Pull Request Sent (was: Open) > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 14 12:29:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 14 Mar 2019 12:29:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3118: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done I'm resolving this issue as I did what was discussed here. if you have some troubles with the current state [~lanceball], please feel free to reopen or create a new issue. Thank you! > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 14 13:12:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Thu, 14 Mar 2019 13:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708532#comment-13708532 ] Lance Ball commented on JBTM-3118: ---------------------------------- [~ochaloup] thank you! > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 15 08:54:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Fri, 15 Mar 2019 08:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708940#comment-13708940 ] Lance Ball commented on JBTM-3118: ---------------------------------- Just writing to confirm that I pulled the updates locally and everything is working as expected. Thanks again! > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondra Chaloupka > Priority: Major > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 15 15:25:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Fri, 15 Mar 2019 15:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: Lance Ball created JBTM-3123: -------------------------------- Summary: LRA POST to "start" has Incorrect @ApiResponse annotation Key: JBTM-3123 URL: https://issues.jboss.org/browse/JBTM-3123 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.9.3.Final Reporter: Lance Ball Assignee: Michael Musgrove In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}}, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{200}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 15 15:26:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Fri, 15 Mar 2019 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Ball updated JBTM-3123: ----------------------------- Description: In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}}, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. (was: In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}}, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{200}}.) > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Michael Musgrove > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}}, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 15 15:26:00 2019 From: issues at jboss.org (Lance Ball (Jira)) Date: Fri, 15 Mar 2019 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Ball updated JBTM-3123: ----------------------------- Description: In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. (was: In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}}, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}.) > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Michael Musgrove > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 18 10:23:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 18 Mar 2019 10:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko reassigned JBTM-3123: ------------------------------------- Assignee: Martin Stefanko (was: Michael Musgrove) > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Martin Stefanko > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Mar 18 10:38:00 2019 From: issues at jboss.org (Anonymous (Jira)) Date: Mon, 18 Mar 2019 10:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Martin Stefanko created pull request #1426 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Martin Stefanko > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 03:10:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 03:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3124) io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3124: ------------------------------------- Summary: io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method Key: JBTM-3124 URL: https://issues.jboss.org/browse/JBTM-3124 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.9.3.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The method {{getParentLogger()}} calls itself https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/spi/src/test/java/io/narayana/spi/util/XADSWrapper.java#L125 {code} @Override public Logger getParentLogger() throws SQLFeatureNotSupportedException { return getParentLogger(); } {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 03:34:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 03:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3125) Some LRA&RTS tests uses wrong String.format paramters In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3125: ------------------------------------- Summary: Some LRA&RTS tests uses wrong String.format paramters Key: JBTM-3125 URL: https://issues.jboss.org/browse/JBTM-3125 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA, REST Affects Versions: 5.9.3.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Some tests uses wrong {{String.format}}. For example wrong number of arguments for the {{format}} methdo {code} System.out.printf("SRA: %s: Updating hotel participant state to: ", bookingId, status); {code} should be {code} System.out.printf("SRA: %s: Updating hotel participant state to: %s", bookingId, status); {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 03:36:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 03:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3124) io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1427 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method > -------------------------------------------------------------------------- > > Key: JBTM-3124 > URL: https://issues.jboss.org/browse/JBTM-3124 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The method {{getParentLogger()}} calls itself > https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/spi/src/test/java/io/narayana/spi/util/XADSWrapper.java#L125 > {code} > @Override > public Logger getParentLogger() throws SQLFeatureNotSupportedException { > return getParentLogger(); > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 03:36:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 03:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3125) Some LRA&RTS tests uses wrong String.format paramters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1427 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Some LRA&RTS tests uses wrong String.format paramters > ----------------------------------------------------- > > Key: JBTM-3125 > URL: https://issues.jboss.org/browse/JBTM-3125 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, REST > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Optional > > Some tests uses wrong {{String.format}}. For example wrong number of arguments for the {{format}} methdo > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: ", bookingId, status); > {code} > should be > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: %s", bookingId, status); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 03:38:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 03:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3125) Some LRA&RTS tests uses wrong String.format parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3125: ---------------------------------- Summary: Some LRA&RTS tests uses wrong String.format parameters (was: Some LRA&RTS tests uses wrong String.format paramters) > Some LRA&RTS tests uses wrong String.format parameters > ------------------------------------------------------ > > Key: JBTM-3125 > URL: https://issues.jboss.org/browse/JBTM-3125 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, REST > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Optional > > Some tests uses wrong {{String.format}}. For example wrong number of arguments for the {{format}} methdo > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: ", bookingId, status); > {code} > should be > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: %s", bookingId, status); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 07:42:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 07:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3120) Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3120: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside > ------------------------------------------------------------------------------------------- > > Key: JBTM-3120 > URL: https://issues.jboss.org/browse/JBTM-3120 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > We currently administrate repository https://github.com/jbosstm/jboss-dockerfiles which is out of the date from what is in the jboss generally used https://github.com/jboss-dockerfiles/narayana repository. > We should use the `jboss-dockerfiles/narayana` as it's used by all other projects under JBoss umbrella. > Steps > . retire the https://github.com/jbosstm/jboss-dockerfiles > . move changes done in the `jbosstm/jboss-dockerfiles` to `jboss-dockerfiles/narayana` > . verify if base image used in the LRA coordinator follows those used by other `jboss-dockerfiles` projects -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 07:51:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 07:51:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3123: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1426 > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Martin Stefanko > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 07:52:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 07:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710167#comment-13710167 ] Ondra Chaloupka commented on JBTM-3123: --------------------------------------- [~lanceball] the swagger annotation was changed to reflect the operation. Thanks [~mstefank] for the fix and thanks [~lanceball] for the report. > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Martin Stefanko > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 07:52:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Mar 2019 07:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3123: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Martin Stefanko > Priority: Minor > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 19 13:34:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 19 Mar 2019 13:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3058) Add STM tests that verify nested transactions are closed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3058: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add STM tests that verify nested transactions are closed > -------------------------------------------------------- > > Key: JBTM-3058 > URL: https://issues.jboss.org/browse/JBTM-3058 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > STM implements "Closed Nested Transactions" as opposed to Flattened or Open. We need a test which demonstrates that nested transactions follow the closed model. > Furthermore, STM implementations can differ in how transactional code and non-transactional code are isolated from each other (with respect to visibility of updates during a transaction). Add a test that verifies that we use the "Weak Isolation" model. > Details of the expected behaviour is covered in the Sept 2018 jbossts blog entitled "[Tips on how to evaluate STM implementations|http://example.com|https://jbossts.blogspot.com/2018/09/tips-on-how-to-evaluate-stm.html]" -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 20 05:36:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 20 Mar 2019 05:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3125) Some LRA&RTS tests uses wrong String.format parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3125: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Some LRA&RTS tests uses wrong String.format parameters > ------------------------------------------------------ > > Key: JBTM-3125 > URL: https://issues.jboss.org/browse/JBTM-3125 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, REST > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Optional > > Some tests uses wrong {{String.format}}. For example wrong number of arguments for the {{format}} methdo > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: ", bookingId, status); > {code} > should be > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: %s", bookingId, status); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Mar 20 05:36:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 20 Mar 2019 05:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3124) io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3124: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method > -------------------------------------------------------------------------- > > Key: JBTM-3124 > URL: https://issues.jboss.org/browse/JBTM-3124 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The method {{getParentLogger()}} calls itself > https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/spi/src/test/java/io/narayana/spi/util/XADSWrapper.java#L125 > {code} > @Override > public Logger getParentLogger() throws SQLFeatureNotSupportedException { > return getParentLogger(); > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 22 05:22:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Fri, 22 Mar 2019 05:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3106) Firing an @Initialized(TransactionScoped.class) event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3106: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Firing an @Initialized(TransactionScoped.class) event > ----------------------------------------------------- > > Key: JBTM-3106 > URL: https://issues.jboss.org/browse/JBTM-3106 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Laird Nelson > Priority: Major > Fix For: 5.next > > > It would be beneficial to have the CDI-specific wrapper around Narayana's TransactionManagerImple that fires an @Initialized(TransactionScoped.class)-qualified event. > For the CDI, it's a good practice. The all built-in scopes have to provide this behaviour. > > The CDI specification says (in section 6.7): > {quote} > Portable extensions are encouraged to synchronously fire: > * an event with qualifier @Initialized(X.class) when a custom context is initialized, i.e. ready for use, > * an event with qualifier @BeforeDestroyed(X.class) when a custom context is about to be destroyed, i.e. before the actual destruction, > * an event with qualifier @Destroyed(X.class) when a custom context is destroyed, i.e. after the actual destruction, > where X is the scope type associated with the context. > A suitable event payload should be chosen. > {quote} > > The {{begin()}} method a Narayana-supplied but CDI-specific transaction manager wrapping Narayana's "ordinary" one should do: > {code} > @Inject > @Initialized(TransactionScoped.class) > private Event initializationBroadcaster; > @Inject @BeforeDestroyed(TransactionScoped.class) > private Event beforeDestructionBroadcaster; > @Inject @Destroyed(TransactionScoped.class) > private Event destructionBroadcaster; > // in its begin() method: > super.begin(); > initializationBroadcaster.fire(this.getTransaction()); > // in its commit() and rollback() methods and anywhere else I'm forgetting: > beforeDestructionBroadcaster.fire(this.getTransaction()); > super.commit(); // or rollback or whatever > destructionBroadcaster.fire(this); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 26 11:16:11 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:16:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3056) Remove the xts-test-servlet dependency in narayana-full In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson reassigned JBTM-3056: -------------------------------------- Assignee: Ondrej Chaloupka > Remove the xts-test-servlet dependency in narayana-full > ------------------------------------------------------- > > Key: JBTM-3056 > URL: https://issues.jboss.org/browse/JBTM-3056 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Reporter: Amos Feng > Assignee: Ondrej Chaloupka > Priority: Major > > this dependency is generated by the module XTS/WSAS/xts-test-servlet but does not produce any files. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 26 11:17:01 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:17:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2886) Automatize XTS ssl quickstart to be tested in CI on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson reassigned JBTM-2886: -------------------------------------- Assignee: Ondrej Chaloupka > Automatize XTS ssl quickstart to be tested in CI on Windows > ----------------------------------------------------------- > > Key: JBTM-2886 > URL: https://issues.jboss.org/browse/JBTM-2886 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 4.2 > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > There was created a shell script for JBTM-2882 which automatize testing of XTS over SSL. The steps were already written in `README.md` but that was not run automatically on CI. > The linux version with shell script was provided but we need windows version with `.bat`. This is a followup task to provide the bat script for the automatization on Windows. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 26 11:17:02 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:17:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2830) Consider possible compensations framework architecture improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson reassigned JBTM-2830: -------------------------------------- Assignee: Ondrej Chaloupka > 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: Ondrej Chaloupka > Priority: Major > > 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.12.1#712002) From issues at jboss.org Tue Mar 26 11:25:00 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3019) Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-3019. ---------------------------------- Fix Version/s: (was: 5.next) Resolution: Migrated to another ITS Other ITS is: https://github.com/web-servers/narayana-tomcat/issues > Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time > ------------------------------------------------------------------------------------------------- > > Key: JBTM-3019 > URL: https://issues.jboss.org/browse/JBTM-3019 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.8.1.Final > Environment: Docker enabled Jenkins slaves > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Minor > > h3. Problem > The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images: > {code} > [root at karm-centos7-x86-64 ~]# docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > docker.io/postgres 9.4 26bd9b04b948 6 days ago 232 MB > docker.io/postgres 10 0965cdc98045 6 days ago 234 MB > docker.io/postgres ed5db6e669ff 7 weeks ago 263 MB > docker.io/postgres 30121e967865 7 weeks ago 289 MB > [root at karm-centos7-x86-64 ~]# docker ps -a > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > [root at karm-centos7-x86-64 ~]# > {code} > Although it leaves stray container volumes for some reason: > {code} > [root at karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes > 15G /var/lib/docker-latest/volumes > [root at karm-centos7-x86-64 ~]# docker volume ls -qf dangling=true | wc -l > 409 > {code} > It unnecessarily clogs the slaves' disk space. The 15G of garbage has been created over dozens and dozens of builds with at least two containers each, but it shouldn't be happening anyway. > h3. Call to action > Review whether [removeContainerCmd|https://github.com/jbosstm/narayana/blob/master/tools/src/main/java/io/narayana/db/PostgreContainerAllocator.java#L264] is supposed to be enough to not only remove the container but to also remove its volume. > h3. Workaround > {code} > docker volume prune > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 26 11:27:01 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:27:01 -0400 (EDT) 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 ] Thomas Jenkinson closed JBTM-2799. ---------------------------------- Fix Version/s: (was: 5.later) Resolution: Migrated to another ITS Other ITS is: https://github.com/web-servers/narayana-tomcat/issues > 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: Thomas Jenkinson > Priority: Minor > -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 26 11:31:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:31:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3103) LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson reassigned JBTM-3103: -------------------------------------- Assignee: Michael Musgrove > LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes > -------------------------------------------------------------------------------- > > Key: JBTM-3103 > URL: https://issues.jboss.org/browse/JBTM-3103 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > > This quickstart depends on LRAParticipantDeserializer to recreate participants during crash recovery but [MP LRA issue #61|https://github.com/eclipse/microprofile-lra/issues/61] has removed this class. The alternative registration mechanism is still outstanding [see the comments on issue #35|https://github.com/eclipse/microprofile-lra/issues/35] for a discussion of the new way of registering participants. > Until a PR is raised for this issue I would like to disable the quickstarts that utilise LRAParticipantDeserializer. > Note that this has only just become an issue since previouslythe Narayana implementation of LRA depended on a specific snapshot build in the eclipse repo (since the LRA spec is in flux), but snapshots are purged after a month so the old way of registering participants is no longer available. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Mar 26 11:31:10 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Tue, 26 Mar 2019 11:31:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3103) LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3103: ----------------------------------- Component/s: LRA > LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes > -------------------------------------------------------------------------------- > > Key: JBTM-3103 > URL: https://issues.jboss.org/browse/JBTM-3103 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > > This quickstart depends on LRAParticipantDeserializer to recreate participants during crash recovery but [MP LRA issue #61|https://github.com/eclipse/microprofile-lra/issues/61] has removed this class. The alternative registration mechanism is still outstanding [see the comments on issue #35|https://github.com/eclipse/microprofile-lra/issues/35] for a discussion of the new way of registering participants. > Until a PR is raised for this issue I would like to disable the quickstarts that utilise LRAParticipantDeserializer. > Note that this has only just become an issue since previouslythe Narayana implementation of LRA depended on a specific snapshot build in the eclipse repo (since the LRA spec is in flux), but snapshots are purged after a month so the old way of registering participants is no longer available. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:16:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:16:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3117) Upgrade to the latest LRA spec version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3117: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Upgrade to the latest LRA spec version > -------------------------------------- > > Key: JBTM-3117 > URL: https://issues.jboss.org/browse/JBTM-3117 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > Upgrade to the latest LRA API and TCK snapshots: > ``` > 1.0-20190306.071209-294 > 1.0-20190306.071211-294 > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:16:08 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:16:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3120) Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3120: ----------------------------------- Fix Version/s: 5.next > Moving narayana dockerfiles repository to the repository where all jboss dockerfiles reside > ------------------------------------------------------------------------------------------- > > Key: JBTM-3120 > URL: https://issues.jboss.org/browse/JBTM-3120 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > We currently administrate repository https://github.com/jbosstm/jboss-dockerfiles which is out of the date from what is in the jboss generally used https://github.com/jboss-dockerfiles/narayana repository. > We should use the `jboss-dockerfiles/narayana` as it's used by all other projects under JBoss umbrella. > Steps > . retire the https://github.com/jbosstm/jboss-dockerfiles > . move changes done in the `jbosstm/jboss-dockerfiles` to `jboss-dockerfiles/narayana` > . verify if base image used in the LRA coordinator follows those used by other `jboss-dockerfiles` projects -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:16:08 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:16:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3125) Some LRA&RTS tests uses wrong String.format parameters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3125: ----------------------------------- Fix Version/s: 5.next > Some LRA&RTS tests uses wrong String.format parameters > ------------------------------------------------------ > > Key: JBTM-3125 > URL: https://issues.jboss.org/browse/JBTM-3125 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, REST > Affects Versions: 5.9.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Optional > Fix For: 5.next > > > Some tests uses wrong {{String.format}}. For example wrong number of arguments for the {{format}} methdo > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: ", bookingId, status); > {code} > should be > {code} > System.out.printf("SRA: %s: Updating hotel participant state to: %s", bookingId, status); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:17:04 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:17:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3124) io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3124: ----------------------------------- Fix Version/s: 5.next > io.narayana.spi.util.XADSWrapper infinite loop on getParentLogger() method > -------------------------------------------------------------------------- > > Key: JBTM-3124 > URL: https://issues.jboss.org/browse/JBTM-3124 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > The method {{getParentLogger()}} calls itself > https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/spi/src/test/java/io/narayana/spi/util/XADSWrapper.java#L125 > {code} > @Override > public Logger getParentLogger() throws SQLFeatureNotSupportedException { > return getParentLogger(); > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:17:04 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:17:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3119) Enhance Narayana README with information about tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3119: ----------------------------------- Fix Version/s: 5.next > Enhance Narayana README with information about tests > ---------------------------------------------------- > > Key: JBTM-3119 > URL: https://issues.jboss.org/browse/JBTM-3119 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > The Narayana `README.md` should contain at least few words about type of tests in the Narayana repository. Any newcomer is confused. See https://github.com/jbosstm/narayana/pull/1403#issuecomment-471367319 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:17:05 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:17:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3104: ----------------------------------- Fix Version/s: 5.next > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Thomas Jenkinson > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:17:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:17:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3112) Remove dependency on LRA client from LRA coordinator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3112: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Remove dependency on LRA client from LRA coordinator > ---------------------------------------------------- > > Key: JBTM-3112 > URL: https://issues.jboss.org/browse/JBTM-3112 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > LRA coordinator should not depend on LRA client as these services should be able to operate independently (as separate microservices deployments). -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:20:05 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:20:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3049) Setting properties via arjPropertyManager should affect all related config bean instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3049: ----------------------------------- Fix Version/s: 5.9.2.Final > Setting properties via arjPropertyManager should affect all related config bean instances > ----------------------------------------------------------------------------------------- > > Key: JBTM-3049 > URL: https://issues.jboss.org/browse/JBTM-3049 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.2.Final > > > Narayana configuration is performed through named configuration beans. For example the ObjectStoreEnvironmentBean has three instances for configuring different store types: > * the action store (default) > * the stateStore (with the name "stateStore") > * the communicationsStore (with the name "communicationsStore") > Each of the stores have their own getters and setters. > We also have the arjPropertyManager API which returns the default configuration beans: > {code} > public static CoreEnvironmentBean getCoreEnvironmentBean(); > public static CoordinatorEnvironmentBean getCoordinatorEnvironmentBean(); > public static ObjectStoreEnvironmentBean getObjectStoreEnvironmentBean(); > {code} > For example the getObjectStoreEnvironmentBean() call returns the config for the action store. > Historically (ie before we moved to using configuration beans) the user could set all config properties via the single instance of arjPropertyManager. For example, if the user wanted to disable file system sync'ing for the object store he would obtain an arjuna PropertyManager with which he could set a single property called OBJECTSTORE_SYNC and the setting would be applied to all writes to the object store. However, with the new/current config mechanism he would need to call the setter on each known instance of the ObjectStoreEnvironmentBean: > {code} > BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "communicationStore").setObjectStoreSync(false); > BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "stateStore").setObjectStoreSync(false); > BeanPopulator.getDefaultInstance(ObjectStoreEnvironmentBean.class).setObjectStoreSync(false); > {code} > This JIRA is to return to the original behaviour where calling the setters of the beans returned from arjPropertyManager should be applied to all named instances of the returned bean. > The semantics of calling the getters needs be discussed and defined. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:20:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:20:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3049) Setting properties via arjPropertyManager should affect all related config bean instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-3049. ---------------------------------- > Setting properties via arjPropertyManager should affect all related config bean instances > ----------------------------------------------------------------------------------------- > > Key: JBTM-3049 > URL: https://issues.jboss.org/browse/JBTM-3049 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.2.Final > > > Narayana configuration is performed through named configuration beans. For example the ObjectStoreEnvironmentBean has three instances for configuring different store types: > * the action store (default) > * the stateStore (with the name "stateStore") > * the communicationsStore (with the name "communicationsStore") > Each of the stores have their own getters and setters. > We also have the arjPropertyManager API which returns the default configuration beans: > {code} > public static CoreEnvironmentBean getCoreEnvironmentBean(); > public static CoordinatorEnvironmentBean getCoordinatorEnvironmentBean(); > public static ObjectStoreEnvironmentBean getObjectStoreEnvironmentBean(); > {code} > For example the getObjectStoreEnvironmentBean() call returns the config for the action store. > Historically (ie before we moved to using configuration beans) the user could set all config properties via the single instance of arjPropertyManager. For example, if the user wanted to disable file system sync'ing for the object store he would obtain an arjuna PropertyManager with which he could set a single property called OBJECTSTORE_SYNC and the setting would be applied to all writes to the object store. However, with the new/current config mechanism he would need to call the setter on each known instance of the ObjectStoreEnvironmentBean: > {code} > BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "communicationStore").setObjectStoreSync(false); > BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "stateStore").setObjectStoreSync(false); > BeanPopulator.getDefaultInstance(ObjectStoreEnvironmentBean.class).setObjectStoreSync(false); > {code} > This JIRA is to return to the original behaviour where calling the setters of the beans returned from arjPropertyManager should be applied to all named instances of the returned bean. > The semantics of calling the getters needs be discussed and defined. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:20:09 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:20:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3047) Suspending recovery manager causes deadlock when acive RecoveryMonitor scan request exists In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3047: ----------------------------------- Fix Version/s: 5.9.1.Final > Suspending recovery manager causes deadlock when acive RecoveryMonitor scan request exists > ------------------------------------------------------------------------------------------ > > Key: JBTM-3047 > URL: https://issues.jboss.org/browse/JBTM-3047 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.9.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.1.Final > > > If {{PeriodicMonitor}} has active unfinished request to start recovery scan > {code} > INFO [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:36326) ARJUNA012340: RecoveryManager scan scheduled to begin. > {code} > and meanwhile [the RecoveryManager is suspended|https://github.com/jbosstm/narayana/blob/5.9.0.Final/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java#L256] then the WorkerService is waiting in deadlock forever and JVM can't be cleanly stopped. > The whole stopping EAP server stacktrace could be seen at https://issues.jboss.org/browse/CLOUD-2767 the related Narayana related threads are[10]. > It seems to me as the recovery was put to suspended[1] the processing thread waits for the state change[2]. The state change to set to terminated could be done by periodic recovery shutdown[3] but it's stuck on waiting for listners to be stopped[4]. Stopping the listeners could be done by the thread waiting for the state change[5]. > [1] https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/suspend/RecoverySuspendController.java#L41 > [2] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L348 > [3] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L177 > [4] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L169 > [5] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L387 > [10] > {code} > "Transaction Reaper Worker 0" #121 daemon prio=5 os_prio=0 tid=0x000000000197a000 nid=0x2b6 in Object.wait() [0x00007f3661d2b000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000b289c310> (a java.util.LinkedList) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.arjuna.coordinator.TransactionReaper.waitForCancellations(TransactionReaper.java:328) > - locked <0x00000000b289c310> (a java.util.LinkedList) > at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:65) > Locked ownable synchronizers: > - None > "Transaction Reaper" #120 daemon prio=5 os_prio=0 tid=0x0000000001b4b800 nid=0x2b5 in Object.wait() [0x00007f3661e2c000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000b289c330> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper) > at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:90) > - locked <0x00000000b289c330> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper) > Locked ownable synchronizers: > - None > "Server.Connection:10.130.0.162:46200" #335 daemon prio=5 os_prio=0 tid=0x0000000003853800 nid=0x449 in Object.wait() [0x00007f365ec2c000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:95) > - locked <0x00000000b2916608> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService) > at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88) > Locked ownable synchronizers: > - None > "Server.Connection:10.130.0.162:46090" #225 daemon prio=5 os_prio=0 tid=0x0000000003a4c800 nid=0x3ca in Object.wait() [0x00007f365c2ef000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:95) > - locked <0x00000000b2916608> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService) > at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88) > Locked ownable synchronizers: > - None > "MSC service thread 1-5" #19 prio=5 os_prio=0 tid=0x0000000001903000 nid=0x251 in Object.wait() [0x00007f366aebe000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.Listener.stopListener(Listener.java:222) > - locked <0x00000000b29161d0> (a com.arjuna.ats.internal.arjuna.recovery.Listener) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.shutdown(PeriodicRecovery.java:169) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.stop(RecoveryManagerImple.java:179) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.terminate(RecoveryManager.java:210) > - locked <0x00000000b0badbb8> (a com.arjuna.ats.arjuna.recovery.RecoveryManager) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.terminate(RecoveryManager.java:194) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.stop(RecoveryManagerService.java:73) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.stop(ArjunaRecoveryManagerService.java:167) > - locked <0x00000000b313ddb0> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2150) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2101) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Locked ownable synchronizers: > - <0x00000000b351b500> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "Periodic Recovery" #116 prio=5 os_prio=0 tid=0x0000000002357000 nid=0x2b4 in Object.wait() [0x00007f3661f2d000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doSuspendedWait(PeriodicRecovery.java:709) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:346) > - locked <0x00000000b289c898> (a java.lang.Object) > Locked ownable synchronizers: > - None > {code} > NOTE: there is interesting point there are two {{WorkerService}} instances in the stack trace. It's causes two sequential requests hits the RecoveryManager while the periodic recovery was in progress before the server was shutdown. The code invoking the two calls and then immediately running the shutdown was https://github.com/jboss-openshift/cct_module/blob/7f891cca882f86f983b298b288fe0b5c12bc51bf/os-eap-migration/added/launch/openshift-migrate-common.sh#L50 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:20:12 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:20:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3047) Suspending recovery manager causes deadlock when acive RecoveryMonitor scan request exists In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-3047. ---------------------------------- > Suspending recovery manager causes deadlock when acive RecoveryMonitor scan request exists > ------------------------------------------------------------------------------------------ > > Key: JBTM-3047 > URL: https://issues.jboss.org/browse/JBTM-3047 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.9.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.1.Final > > > If {{PeriodicMonitor}} has active unfinished request to start recovery scan > {code} > INFO [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:36326) ARJUNA012340: RecoveryManager scan scheduled to begin. > {code} > and meanwhile [the RecoveryManager is suspended|https://github.com/jbosstm/narayana/blob/5.9.0.Final/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java#L256] then the WorkerService is waiting in deadlock forever and JVM can't be cleanly stopped. > The whole stopping EAP server stacktrace could be seen at https://issues.jboss.org/browse/CLOUD-2767 the related Narayana related threads are[10]. > It seems to me as the recovery was put to suspended[1] the processing thread waits for the state change[2]. The state change to set to terminated could be done by periodic recovery shutdown[3] but it's stuck on waiting for listners to be stopped[4]. Stopping the listeners could be done by the thread waiting for the state change[5]. > [1] https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/suspend/RecoverySuspendController.java#L41 > [2] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L348 > [3] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L177 > [4] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L169 > [5] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java#L387 > [10] > {code} > "Transaction Reaper Worker 0" #121 daemon prio=5 os_prio=0 tid=0x000000000197a000 nid=0x2b6 in Object.wait() [0x00007f3661d2b000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000b289c310> (a java.util.LinkedList) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.arjuna.coordinator.TransactionReaper.waitForCancellations(TransactionReaper.java:328) > - locked <0x00000000b289c310> (a java.util.LinkedList) > at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:65) > Locked ownable synchronizers: > - None > "Transaction Reaper" #120 daemon prio=5 os_prio=0 tid=0x0000000001b4b800 nid=0x2b5 in Object.wait() [0x00007f3661e2c000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000b289c330> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper) > at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:90) > - locked <0x00000000b289c330> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper) > Locked ownable synchronizers: > - None > "Server.Connection:10.130.0.162:46200" #335 daemon prio=5 os_prio=0 tid=0x0000000003853800 nid=0x449 in Object.wait() [0x00007f365ec2c000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:95) > - locked <0x00000000b2916608> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService) > at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88) > Locked ownable synchronizers: > - None > "Server.Connection:10.130.0.162:46090" #225 daemon prio=5 os_prio=0 tid=0x0000000003a4c800 nid=0x3ca in Object.wait() [0x00007f365c2ef000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:95) > - locked <0x00000000b2916608> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService) > at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88) > Locked ownable synchronizers: > - None > "MSC service thread 1-5" #19 prio=5 os_prio=0 tid=0x0000000001903000 nid=0x251 in Object.wait() [0x00007f366aebe000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.Listener.stopListener(Listener.java:222) > - locked <0x00000000b29161d0> (a com.arjuna.ats.internal.arjuna.recovery.Listener) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.shutdown(PeriodicRecovery.java:169) > at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.stop(RecoveryManagerImple.java:179) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.terminate(RecoveryManager.java:210) > - locked <0x00000000b0badbb8> (a com.arjuna.ats.arjuna.recovery.RecoveryManager) > at com.arjuna.ats.arjuna.recovery.RecoveryManager.terminate(RecoveryManager.java:194) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.stop(RecoveryManagerService.java:73) > at org.jboss.as.txn.service.ArjunaRecoveryManagerService.stop(ArjunaRecoveryManagerService.java:167) > - locked <0x00000000b313ddb0> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2150) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2101) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Locked ownable synchronizers: > - <0x00000000b351b500> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "Periodic Recovery" #116 prio=5 os_prio=0 tid=0x0000000002357000 nid=0x2b4 in Object.wait() [0x00007f3661f2d000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doSuspendedWait(PeriodicRecovery.java:709) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:346) > - locked <0x00000000b289c898> (a java.lang.Object) > Locked ownable synchronizers: > - None > {code} > NOTE: there is interesting point there are two {{WorkerService}} instances in the stack trace. It's causes two sequential requests hits the RecoveryManager while the periodic recovery was in progress before the server was shutdown. The code invoking the two calls and then immediately running the shutdown was https://github.com/jboss-openshift/cct_module/blob/7f891cca882f86f983b298b288fe0b5c12bc51bf/os-eap-migration/added/launch/openshift-migrate-common.sh#L50 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:21:09 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:21:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3040) Include more logging in LRA state changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3040: ----------------------------------- Fix Version/s: 5.9.1.Final > Include more logging in LRA state changes > ----------------------------------------- > > Key: JBTM-3040 > URL: https://issues.jboss.org/browse/JBTM-3040 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.1.Final > > > We have a test that fails fairly regulary due to timeout: > Tests run: 26, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 98.564 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT > timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 0.868 sec <<< FAILURE! > java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> > at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:608) > Results : > Failed tests: > SpecIT.timeLimitRequiredLRA:608 timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:21:11 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:21:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3040) Include more logging in LRA state changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-3040. ---------------------------------- > Include more logging in LRA state changes > ----------------------------------------- > > Key: JBTM-3040 > URL: https://issues.jboss.org/browse/JBTM-3040 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.1.Final > > > We have a test that fails fairly regulary due to timeout: > Tests run: 26, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 98.564 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT > timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 0.868 sec <<< FAILURE! > java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> > at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:608) > Results : > Failed tests: > SpecIT.timeLimitRequiredLRA:608 timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:21:15 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:21:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3085) Compensations test fail because of WildFly module changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3085: ----------------------------------- Fix Version/s: 5.9.2.Final > Compensations test fail because of WildFly module changes > --------------------------------------------------------- > > Key: JBTM-3085 > URL: https://issues.jboss.org/browse/JBTM-3085 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Affects Versions: 5.9.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.2.Final > > > There was change in module dependencies for compensations (see at https://issues.jboss.org/browse/WFLY-11421) which requires changes into testsuite of compensations. > Currently the narayana CI XTS tests are failing. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:21:16 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:21:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3085) Compensations test fail because of WildFly module changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-3085. ---------------------------------- > Compensations test fail because of WildFly module changes > --------------------------------------------------------- > > Key: JBTM-3085 > URL: https://issues.jboss.org/browse/JBTM-3085 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Affects Versions: 5.9.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.2.Final > > > There was change in module dependencies for compensations (see at https://issues.jboss.org/browse/WFLY-11421) which requires changes into testsuite of compensations. > Currently the narayana CI XTS tests are failing. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:22:09 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:22:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2920) Investigate the use of transactions within a reactive microservices environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-2920. ---------------------------------- > Investigate the use of transactions within a reactive microservices environment > ------------------------------------------------------------------------------- > > Key: JBTM-2920 > URL: https://issues.jboss.org/browse/JBTM-2920 > Project: JBoss Transaction Manager > Issue Type: Task > Environment: * > Reporter: Ondrej Chaloupka > Assignee: Martin Stefanko > Priority: Major > Labels: student > > Investigate the use of a transaction manager when used within a reactive microservices environment[1][2]. > h2. Motivation > Reactive microservice architecture is a trending architectural pattern. The reactive architecture could simply be defined as a system where messages are sent to a jms queue or a specialized event storage and other services are registered to, for being notified when an event is generated to be able to react on it. Synchronous calls from a service to a service are not meant to be a good practice in such system. Here all the communication between services is done with message passing through the event storage. > Such a system is expected to decouple data [3] where each microservice manages data, which needs for working, on its own. Still there are cases where some data coordination is needed. As the all communication is asynchronous it may be that we need to modify the transaction manager away from synchronous operations. One possibly good match seems to be the Saga transactions[4] and eventual consistency[5][6] but handling of them is fitting to the message driven system. The way of understanding Saga in microservice world could be overviewed at [15]. > Narayana transaction manager is good in managing Saga transactions where having long history experience from running it for WS[7] or managing consistency in NoSQL databases[8]. But Narayana is designed to manage transactions in synchronous way. The transaction context is normally passed along a RPC call where the transaction is finished after such synchronous call is returned back to the caller. > h2. Steps to go > The point here is to investigate on the topic of usage Saga in reactive architecture, gather working solutions - especially in Java world (some references eg. [9][10][11][12][13][14]), get experience in how they are working and on top of this experience considering implementation of the reactive approach with Narayana. It may be that Narayana requires some modification to execute optimally for such task and then it?s up to reconsideration if some greenfield implementation should be started. As the last step there should be created some sample project (ie. quickstart) where the usage of the implementation would be shown. > With that we expect usage of projects in Red Hat portfolio. The sample project would be probably implemented with usage of the Vert.x, meybe there could be considered usage of Infinispan or AMQ7 for handling events. > h2. Expected output > The expected output of this effort is > * A research document with state of the art. > ** Overview of what are the problem of the synchronous/blocking approach. > ** What are the other approaches that people have to this problem, > * A proof-of-concept implementation > ** Preferably with use of Narayana transaction manager prepare a service capable to manage transactions in world of reactive microservices > * An example/quickstart showing this in practical terms > ** A proof that a transaction manager can be made to work in an asynchronous environment. For example if you have a Vert.x event and it has to commit a transaction. The handler for that message currently does sync ops with transaction manager and that blocks. One of the goals for the project is to prevent blocking of threads in an async environment. > h2. Resources > [1] [https://www.youtube.com/watch?v=STKCRSUsyP0|https://www.youtube.com/watch?v=STKCRSUsyP0](GOTO 2017, The Many Meanings of Event-Driven Architecture, Martin Fowler) > [2] [http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp] (Reactive Microservices Architecture) > [3] [http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data] (The Hardest Part About Microservices: Your Data) > [4] [https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf] (Sagas paper) > [5] [http://queue.acm.org/detail.cfm?id=2462076] (Eventual Consistency Today: Limitations, Extensions, and Beyond) > [6] [http://queue.acm.org/detail.cfm?id=3025012] (Life Beyond Distributed Transactions) > [7] [http://narayana.io//docs/project/index.html#d0e14874] (Narayana doc, WS-Business Activity) > [8] [http://jbossts.blogspot.cz/2014/05/bringing-transactional-guarantees-to.html] (Bringing Transactional Guarantees to MongoDB) > [9] [https://www.youtube.com/watch?v=0UTOLRTwOX0] (Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17) > [10] [https://www.youtube.com/watch?v=YPbGW3Fnmbc] (Using sagas to maintain data consistency in a microservice architecture by Chris Richardson) > [11] [http://www.axonframework.org] > [12] [http://eventuate.io] > [13] [https://docs.particular.net/nservicebus/sagas] (.NET NServiceBus Saga) > [14] [https://www.youtube.com/watch?v=Rm8n-H6zI1k] (Dr. Roland Kuhn: Reactive Design Patterns, Akka) > [15] [http://microservices.io/patterns/data/saga.html] (Pattern: Saga) -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:23:02 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:23:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2942) LRA tests failed when building with the JDK9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-2942: ----------------------------------- Fix Version/s: 5.9.1.Final > LRA tests failed when building with the JDK9 > -------------------------------------------- > > Key: JBTM-2942 > URL: https://issues.jboss.org/browse/JBTM-2942 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Amos Feng > Assignee: Michael Musgrove > Priority: Major > Labels: jdk9 > Fix For: 5.9.1.Final > > > The lra-test still failed with java.lang.IllegalArgumentException when deploying the war. It looks like the wildfly-swarm does support the JDK9 currently. Also I find 1 and 2 with the same issues. > 1. https://stackoverflow.com/questions/46449735/wildfly-swarm-deployment-crash-with-java-9 > 2. https://stackoverflow.com/questions/42990017/illegalargumentexception-while-starting-wildfly-swarm-provided-custom-main-meth -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:23:03 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:23:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2942) LRA tests failed when building with the JDK9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-2942. ---------------------------------- > LRA tests failed when building with the JDK9 > -------------------------------------------- > > Key: JBTM-2942 > URL: https://issues.jboss.org/browse/JBTM-2942 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Amos Feng > Assignee: Michael Musgrove > Priority: Major > Labels: jdk9 > Fix For: 5.9.1.Final > > > The lra-test still failed with java.lang.IllegalArgumentException when deploying the war. It looks like the wildfly-swarm does support the JDK9 currently. Also I find 1 and 2 with the same issues. > 1. https://stackoverflow.com/questions/46449735/wildfly-swarm-deployment-crash-with-java-9 > 2. https://stackoverflow.com/questions/42990017/illegalargumentexception-while-starting-wildfly-swarm-provided-custom-main-meth -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:24:04 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:24:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-2685: ----------------------------------- Fix Version/s: 5.9.1.Final > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Critical > Fix For: 5.9.1.Final > > > **(some commits that reference this issue are actually for https://issues.jboss.org/browse/JBTM-2955)** > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:24:05 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:24:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson closed JBTM-2685. ---------------------------------- > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Critical > Fix For: 5.9.1.Final > > > **(some commits that reference this issue are actually for https://issues.jboss.org/browse/JBTM-2955)** > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:24:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:24:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3118) Protocol family unavailable error in lra-coordinator Docker container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3118: ----------------------------------- Fix Version/s: 5.next > Protocol family unavailable error in lra-coordinator Docker container > --------------------------------------------------------------------- > > Key: JBTM-3118 > URL: https://issues.jboss.org/browse/JBTM-3118 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > Attempting to run the `lra-coordinator` image, it silently fails. So I started the container using this command. > ```sh > docker run --rm -it -p 8080:8080 jbosstm/lra-coordinator /bin/bash > ``` > Running the command `java -jar lra-coordinator.jar` from the `deployments` directory produces the following output before the process dies. > ```log > 2019-03-08 19:11:57,808 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:181) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169) > ... 5 more > 2019-03-08 19:11:57,846 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("http-listener" => "default") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.undertow.listener.default" => "WFLYUT0082: Could not start 'default' listener. > Caused by: java.net.SocketException: Protocol family unavailable"}} > ``` > I can successfully start the coordinator from within the container by specifying a preference for the IPv4 stack using the following command. > ```sh > java -Djava.net.preferIPv4Stack=true -jar lra-coordinator-swarm.jar > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:24:08 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:24:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3123) LRA POST to "start" has Incorrect @ApiResponse annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3123: ----------------------------------- Fix Version/s: 5.next > LRA POST to "start" has Incorrect @ApiResponse annotation > --------------------------------------------------------- > > Key: JBTM-3123 > URL: https://issues.jboss.org/browse/JBTM-3123 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Lance Ball > Assignee: Martin Stefanko > Priority: Minor > Fix For: 5.next > > > In {{java.io.narayana.lra.coordinator.api.Coordinator}} the {{@ApiResponse}} annotation [specifies a response code |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L227] of {{200}} for the "start" endpoint, however, [what is actually returned |https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/api/Coordinator.java#L281] is {{Response.Status.CREATED}} which is HTTP code {{201}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:26:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:26:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3070) Quickstart for transaction driver should not be using reflection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3070: ----------------------------------- Fix Version/s: 5.next > Quickstart for transaction driver should not be using reflection > ---------------------------------------------------------------- > > Key: JBTM-3070 > URL: https://issues.jboss.org/browse/JBTM-3070 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > Currently the quickstart of transaction driver standalone uses reflection for forcibly closing H2 connection. It was used as a way to overcome the H2 issues with XA connection. > As the quickstart tests recovery it arbitrary throws an exception. This makes issue for H2 as it consider the connection as unfinished but if we close it it does not care and sets autocommit to true and let all the changes being immediately propagated to database. > That's what we don't want as we test recovery and we expect recovery to finish the in-doubt data. > The issue is only for H2 behaviour. "Normal" databases as PostgreSQL makes checks on unfinished transaction in jdbc driver and their decisions are based on it. > Nevertheless using reflection is not a good habit and it's a hacky. For quickstarts it should not be the case. There needs to be a way how to avoid it. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:26:11 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:26:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3069) XTS over SSL Quickstart failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3069: ----------------------------------- Fix Version/s: 5.next > XTS over SSL Quickstart failed > ------------------------------ > > Key: JBTM-3069 > URL: https://issues.jboss.org/browse/JBTM-3069 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing, XTS > Reporter: Amos Feng > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:05 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3116) Temporarily disable LRA quickstarts until the MP LRA spec is more stable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3116: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Temporarily disable LRA quickstarts until the MP LRA spec is more stable > ------------------------------------------------------------------------ > > Key: JBTM-3116 > URL: https://issues.jboss.org/browse/JBTM-3116 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The MP LRA draft spec has recently undergone a lot of churn and we need to bring both the narayana implementation and the quickstarts into line with those changes. While that work is being undertaken the quickstarts should be disabled so that users and CI do not use non-working examples. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:06 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3105) STM TaxonomyTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3105: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > STM TaxonomyTest failure > ------------------------ > > Key: JBTM-3105 > URL: https://issues.jboss.org/browse/JBTM-3105 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > There was test failure during a CI PR test: testIsClosedNestedParentNotVisible(org.jboss.stm.TaxonomyTest) on job > http://narayanaci1.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/jdk=jdk9.latest,label=catelyn/12/ -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3090) LRA TCK failures need to report more context to facilitate debugging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3090: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > LRA TCK failures need to report more context to facilitate debugging > -------------------------------------------------------------------- > > Key: JBTM-3090 > URL: https://issues.jboss.org/browse/JBTM-3090 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test failure message reports > > failures.forEach(f -> System.out.printf("%s%n", f)); > where f is the failure reason. There is also a verbose option which prints out the stack trace where the failure was reported. But in some failure cases these two pieces of information are insufficient to debug the failure. It would be nice if the resources that participated in the test also logged information which could be reported for more effective analysis of the reasons for the failure. This last requirement may affect the TCK itself so the code in the eclipse microprofile-lra repo should be analysed as well. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:07 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3089) LRA code improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3089: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > LRA code improvements > --------------------- > > Key: JBTM-3089 > URL: https://issues.jboss.org/browse/JBTM-3089 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Remove TODO comments from the code and replace with JIRA issues. > Ensure that the message string in all occurrences of GenericLRAException are meaningful. > Remove all commented out pieces of code. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:08 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3073) Do not mandate JAX-RS annotations on @Compensate/@Complete methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3073: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Do not mandate JAX-RS annotations on @Compensate/@Complete methods > ------------------------------------------------------------------ > > Key: JBTM-3073 > URL: https://issues.jboss.org/browse/JBTM-3073 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Cloned from [https://github.com/eclipse/microprofile-lra/issues/35|http://example.com]: > It is up to the implementation on how the Compensate methods are called. > This could be through JAX-RS calls but this should not be the only way (although an implementation will probably only implement one method). This makes it easier to use the 'events' way of coordination. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:09 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3072) Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3072: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose > ---------------------------------------------------------------------------------------- > > Key: JBTM-3072 > URL: https://issues.jboss.org/browse/JBTM-3072 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Add a test that verifies the correct behaviour when a method is annotated with both REQUIRES_NEW and delayClose, ie something like: > {code} > @PUT > @Path(ActivityController.ACCEPT_WORK) > @LRA(value = LRA.Type.REQUIRES_NEW, delayClose = true) > public Response doInNewLRA( ....) {...} > {code} > The expected behaviour is: > {code} > /** > * If called outside a LRA context a new LRA will be created for the > * the duration of the method call and when the call completes it will > * be closed (this behaviour can be overridden using the > * {@link LRA#delayClose} attribute). > * > * If called inside a LRA context it will be suspended and a new LRA > * context will be created for the duration of the call. When the method > * finishes this new LRA will be closed and the original context will be > * resumed. This behaviour can be overridden using the > * {@link LRA#delayClose} attribute) in which case the original LRA > * remains suspended and the new LRA becomes the active one and only > * when that one is terminated will the original context be resumed. > */ > REQUIRES_NEW, > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:10 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3071) Windows automation of the LRA examples quickstarts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3071: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Windows automation of the LRA examples quickstarts > -------------------------------------------------- > > Key: JBTM-3071 > URL: https://issues.jboss.org/browse/JBTM-3071 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA examples quickstarts (https://issues.jboss.org/browse/JBTM-3063) contain a bash script to run the examples. We need the equivalent for running on Windows. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:10 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3062) Include a test for LRA context propagation across a "non-LRA aware" service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3062: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Include a test for LRA context propagation across a "non-LRA aware" service > --------------------------------------------------------------------------- > > Key: JBTM-3062 > URL: https://issues.jboss.org/browse/JBTM-3062 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and service A in turn calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. A test is needed for this behaviour. > This issue relates to https://github.com/eclipse/microprofile-lra/issues/7 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:11 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3051) LRA test timeLimit failure on JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3051: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > LRA test timeLimit failure on JDK 9 > ----------------------------------- > > Key: JBTM-3051 > URL: https://issues.jboss.org/browse/JBTM-3051 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Whilst fixing issue JBTM-2942 I noticed that the test timeLimitRequiredLRA fails consistently with the reason: > {quote} > 2018-08-14 11:38:00,244 INFO [stdout] (pool-7-thread-1) testName.getMethodName(): WARNING: test did not close http://localhost:8080/lra-coordinator/0_ffff0a3f00d6_245c07ef_5b72b0d1_104 > {quote} > I have temporarily disabled the test in the TCK runner: > {quote} > rts/lra/lra-tck/tck/src/main/java/org/eclipse/microprofile/lra/tck/RunTck.java > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:12 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3046: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > REST-AT PerformanceTest occasionally hangs on Windows CI runs > ------------------------------------------------------------- > > Key: JBTM-3046 > URL: https://issues.jboss.org/browse/JBTM-3046 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > Attachments: threaddump.txt > > > The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest > See the attachment for the stacktraces. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:13 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3020: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:14 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:14 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2968) Some JTS quickstarts run with JacORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-2968: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Some JTS quickstarts run with JacORB > ------------------------------------ > > Key: JBTM-2968 > URL: https://issues.jboss.org/browse/JBTM-2968 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Some of the JTS quickstarts are using JacORB. The narayana project has since changed the default ORB (OpenJDK ORB) so we should change the quickstarts to use the new default. The affected poms are: > ArjunaJTS/pom.xml > ArjunaJTS/standalone/pom.xml > ArjunaJTS/trailmap/pom.xml -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:15 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-2967: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Some quickstarts are not tested in CI > ------------------------------------- > > Key: JBTM-2967 > URL: https://issues.jboss.org/browse/JBTM-2967 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage. > This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart. > The following poms do execute a run script > transactionaldriver-jpa-and-tomcat/pom.xml > rts/at/simple/pom.xml > rts/lra/lra-test/pom.xml > ArjunaJTS/interop/glassfish/pom.xml > transactionaldriver-and-tomcat/pom.xml > spring/camel-with-narayana-spring-boot/pom.xml > The following quickstarts contain run scripts: > transactionaldriver-jpa-and-tomcat/run.sh > ArjunaCore/txoj/run.sh > jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh > ArjunaJTA/object_store/run.sh > ArjunaJTA/maven/run.sh > ArjunaJTA/recovery/run.sh > ArjunaJTA/javax_transaction/run.sh > rts/at/undertow/run.sh > rts/at/recovery/recovery2/run.sh > rts/at/recovery/recovery1/run.sh > rts/at/simple/run.sh > rts/at/service/service2b/run.sh > rts/at/service/service2/run.sh > rts/at/service/service1b/run.sh > rts/at/service/service1/run.sh > rts/at/demo/run.sh > rts/lra/run.sh > ArjunaJTS/standalone/run.sh > ArjunaJTS/interop/glassfish/run.sh > ArjunaJTS/recovery/run.sh -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:16 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-2912: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Thomas Jenkinson > Priority: Major > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Mar 28 10:36:16 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Thu, 28 Mar 2019 10:36:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-2867: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703 > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 29 17:16:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Fri, 29 Mar 2019 17:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3126) @LRA may begin a nested LRA without the presence of @NestedLRA In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3126: -------------------------------------- Summary: @LRA may begin a nested LRA without the presence of @NestedLRA Key: JBTM-3126 URL: https://issues.jboss.org/browse/JBTM-3126 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next If a JAX-RS method is invoked and the following conditions are met: - the invoked method is annotated with LRA.Type.REQUIRES_NEW; - the invoked method is not annotated with @Nested; - there is an LRA context present on the incoming request then the implementation (of the LRA spec) will begin a nested LRA which is contrary to the specified behaviour. Note that there is an [outstanding issue regarding nested LRAs|https://github.com/eclipse/microprofile-lra/issues/117] but this issue affects the implementation of the current specification and needs fixing. In addition there is also the situation where the outbound JAX-RS request filter may override the LRA context header (this issue can be reproduced by starting an LRA and then starting a JAX-RS request with a different "LRA context header" - the expected behaviour in this case is to run the request with the context set by the user. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 29 17:31:01 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Fri, 29 Mar 2019 17:31:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3126) @LRA may begin a nested LRA without the presence of @NestedLRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1432 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > @LRA may begin a nested LRA without the presence of @NestedLRA > --------------------------------------------------------------- > > Key: JBTM-3126 > URL: https://issues.jboss.org/browse/JBTM-3126 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If a JAX-RS method is invoked and the following conditions are met: > - the invoked method is annotated with LRA.Type.REQUIRES_NEW; > - the invoked method is not annotated with @Nested; > - there is an LRA context present on the incoming request > then the implementation (of the LRA spec) will begin a nested LRA which is contrary to the specified behaviour. Note that there is an [outstanding issue regarding nested LRAs|https://github.com/eclipse/microprofile-lra/issues/117] but this issue affects the implementation of the current specification and needs fixing. > In addition there is also the situation where the outbound JAX-RS request filter may override the LRA context header (this issue can be reproduced by starting an LRA and then starting a JAX-RS request with a different "LRA context header" - the expected behaviour in this case is to run the request with the context set by the user. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Mar 29 19:24:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Fri, 29 Mar 2019 19:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3127) LRA TCK Test Failure (mixedMultiLevelNestedActivity) In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3127: -------------------------------------- Summary: LRA TCK Test Failure (mixedMultiLevelNestedActivity) Key: JBTM-3127 URL: https://issues.jboss.org/browse/JBTM-3127 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next This TCK failure was introduced when MP-LRA PR https://github.com/eclipse/microprofile-lra/pull/115 removed the Java Client API. -- This message was sent by Atlassian Jira (v7.12.1#712002)