May 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBTM-3020: ------------------------------ Description: As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: {code:java} int endWithResult(Xid xid, int flags) throws XAException; {code} The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. Since it's a subinterface of {{XAResource}}, it could also define the following default method: {code:java} default void end(Xid xid, int flags) throws XAException { endWithResult(xid, flags); } {code} This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. was: As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: {code:java} int endWithResult(Xid xid, int flags) throws XAException; {code} The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. Since it's a subinterface of {{XAResource}}, it could also define the following default method: {code:java} default void end(Xid xid, int flags) throws XAException { endWithResult(xid, flags); } {code} This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3020: -------------------------------- Fix Version/s: 5.next > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-3020: ----------------------------------- Assignee: Ondra Chaloupka > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

by David Lloyd (JIRA)

David Lloyd created JBTM-3020: --------------------------------- Summary: Add ability for resources to indicate XA_RDONLY on end Key: JBTM-3020 URL: https://issues.jboss.org/browse/JBTM-3020 Project: JBoss Transaction Manager Issue Type: Feature Request Reporter: David Lloyd As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: {code:java} int endWithResult(Xid xid, int flags) throws XAException; {code} The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. Since it's a subinterface of {{XAResource}}, it could also define the following default method: {code:java} default void end(Xid xid, int flags) throws XAException { endWithResult(xid, flags); } {code} This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3016) NoSuchFieldException throws when setting the pool properties

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3016?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Amos Feng created pull request #1311 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > NoSuchFieldException throws when setting the pool properties > ------------------------------------------------------------ > > Key: JBTM-3016 > URL: https://issues.jboss.org/browse/JBTM-3016 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3016) NoSuchFieldException throws when setting the pool properties

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3016?page=com.atlassian.jira.plugin.... ] Amos Feng reopened JBTM-3016: ----------------------------- I have to reopen this issue to update to use the BasicManagedDataSource > NoSuchFieldException throws when setting the pool properties > ------------------------------------------------------------ > > Key: JBTM-3016 > URL: https://issues.jboss.org/browse/JBTM-3016 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3016) NoSuchFieldException throws when setting the pool properties

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3016?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3016: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > NoSuchFieldException throws when setting the pool properties > ------------------------------------------------------------ > > Key: JBTM-3016 > URL: https://issues.jboss.org/browse/JBTM-3016 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3016) NoSuchFieldException throws when setting the pool properties

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3016?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Amos Feng created pull request #1310 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > NoSuchFieldException throws when setting the pool properties > ------------------------------------------------------------ > > Key: JBTM-3016 > URL: https://issues.jboss.org/browse/JBTM-3016 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > I think there are only "maxTotal", "maxIdle" and "minIdle" in the GenericObjectPoolConfig, the others are in its parent class BaseObjectPoolConfig. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3018) Migrate the LRA implementation to use the microprofile-lra API

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1308 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Migrate the LRA implementation to use the microprofile-lra API > -------------------------------------------------------------- > > Key: JBTM-3018 > URL: https://issues.jboss.org/browse/JBTM-3018 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api). > Make sure the API bundled with narayana is deprecated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3019) Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created JBTM-3019: ----------------------------------------- Summary: Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time Key: JBTM-3019 URL: https://issues.jboss.org/browse/JBTM-3019 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.8.1.Final Environment: Docker enabled Jenkins slaves Reporter: Michal Karm Babacek Assignee: Michal Karm Babacek Priority: Minor Fix For: 5.next h3. Problem The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images: {code} [root@karm-centos7-x86-64 ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/postgres 9.4 26bd9b04b948 6 days ago 232 MB docker.io/postgres 10 0965cdc98045 6 days ago 234 MB docker.io/postgres <none> ed5db6e669ff 7 weeks ago 263 MB docker.io/postgres <none> 30121e967865 7 weeks ago 289 MB [root@karm-centos7-x86-64 ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES [root@karm-centos7-x86-64 ~]# {code} Although it leaves stray container volumes for some reason: {code} [root@karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes 15G /var/lib/docker-latest/volumes [root@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/...] is supposed to be enough to not only remove the container but to also remove its volume. h3. Workaround {code} docker volume prune {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2018