October 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2953) Support asynchronous LRA participants

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2953: -------------------------------------- Summary: Support asynchronous LRA participants Key: JBTM-2953 URL: https://issues.jboss.org/browse/JBTM-2953 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later When an asynchronous jax-rs method is annotated as an LRA (ie has the @LRA annotation), for example: {code} @GET @LRA public void someAction(@Suspended AsyncResponse ar) throws InterruptedException { ... } {code} the LRA filter does not respect the asynchronous nature of the call. What needs to happen is for LRA jax-rs filter (ServerLRAFilter.java) to issue an asynchronous join request to the coordinator and to link that future to the jax-rs resource AsyncResponse callback. And since the ServerLRAFilter cannot immediately supply the LRAId to the resource method we also need a method on LRAClient analogous to getCurrent but which returns a Future for the lra id. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1242 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1241 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2952: ------------------------------------- Summary: LRA rest cdi checker should not demand @Status Key: JBTM-2952 URL: https://issues.jboss.org/browse/JBTM-2952 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1240 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-2951: --------------------------------------- these warnings are caused by registration of the REST provider - once via {{@Provider}} annotation, second via descriptor {{javax.ws.rs.ext.Providers}}. Only one way should be enough. > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2951: ------------------------------------- Summary: Application using LRAClient starts with multiple warnings Key: JBTM-2951 URL: https://issues.jboss.org/browse/JBTM-2951 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor When starting an application using {{LRAClient}} I get several warnings during startup {code} 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2950: ------------------------------------- Summary: LRA logging is wrong in pointing to tsLogger and using System.out Key: JBTM-2950 URL: https://issues.jboss.org/browse/JBTM-2950 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. Up to that there should be more consistency and more informative for user. * There are hidden reasons of some failures in some places. * The error messages get from the URL queries are unclear in some cases, e.g. {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2949: ---------------------------------------- I have taken a look back at older version of the code and we have already had four goes at implementing this (although we haven't tried Luis's approach): Fix 1: removeChildThread(Thread.currentThread().getName()); Fix 2 (JBOSSTS_4_2_2_GA): final String threadId = Integer.toHexString(System.identityHashCode(t)) ; Fix 3 (JBOSSTS_4_2_3_GA):_childThreads.put(ThreadUtil.getThreadId(t), t); Fix 4: the one that Tom did in the 5 stream. Clearly there is a history of getting this wrong and I would prefer not to try a new implementation without being able to quantify the benefit (I am not say there is no benefit but we need to see the numbers). > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-989) Consider using a common code style throughout Narayana

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s... ] Ondra Chaloupka commented on JBTM-989: -------------------------------------- the LRA modules contains the checkstyle to have unified coding style based on the WFLY one: https://github.com/jbosstm/narayana/pull/1239 > Consider using a common code style throughout Narayana > ------------------------------------------------------ > > Key: JBTM-989 > URL: https://issues.jboss.org/browse/JBTM-989 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 4.17.0.M1/5.0.0.M1 > Reporter: Paul Robinson > Assignee: Tom Jenkinson > > I think we should consider using a common code style throughout the TS project. The benefits of doing this are as follows: > # You can automate code formatting. This is a real productivity boost as you can type away, thinking about your code, rather than the style. When you hit save, or trigger it directly, the code is formatted. > ## This is not possible without a project wide code style as you too frequently re-format code that needs to stay in someone else's personal style. You can't commit this changed code as; a) it may annoy the "owner" and b) it results in a change that can't be diffed (every line may be changed). > # We get consistency over the whole project, making it easier to read code written by others. > # We have to do this anyway for code we maintain inside the JBossAS project as the project refuses to build if it doesn't adhere to their style. > Personally, I like the style I've used for the last 10 years. I find it harder to read code that is not in this style. Hence I can understand why people may object to changing their style. However, this is the very reason why a common style is beneficial. You can get used to a new style and once you do, the entire project will be styled in the way that you are used to. Providing the style is sensible, I would much rather use a style consistent across the projects I work on. I'm happy for that style to be different to my current style. > As I stated above JBossAS mandates a style at build time. I don't particularly like the style (braces should occupy their own line, IMO) but I'm happy to go with this one if it becomes the Narayana standard style. > I think we should also break the build for violations. This should prevent mistakes making their way into SVN. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2017