May 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3014) Support all the pooling parameters of the DBCP2 in the TransactionalDataSourceFactory

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3014?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-3014. --------------------------- > Support all the pooling parameters of the DBCP2 in the TransactionalDataSourceFactory > ------------------------------------------------------------------------------------- > > Key: JBTM-3014 > URL: https://issues.jboss.org/browse/JBTM-3014 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.8.2.Final > > > Currently we just support the minIdle, maxIdle, maxTotal and it needs to support all the configuration parameters [1]. > [1] https://commons.apache.org/proper/commons-dbcp/configuration.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3013) Update Tomcat integration test to be able to use Postgres database

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3013?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-3013. --------------------------- > Update Tomcat integration test to be able to use Postgres database > ------------------------------------------------------------------ > > Key: JBTM-3013 > URL: https://issues.jboss.org/browse/JBTM-3013 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tomcat > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.8.2.Final > > > Currently it uses H2 but it would be useful to demonstrate this working on Postgres too -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3012) Cache recovery connection in Tomcat integration

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3012?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-3012. --------------------------- > Cache recovery connection in Tomcat integration > ----------------------------------------------- > > Key: JBTM-3012 > URL: https://issues.jboss.org/browse/JBTM-3012 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tomcat > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.8.2.Final > > > The current TransactionalDataSourceFactory allocates a new XAConnection per recovery manager cycle. It would be better to close it or cache it so we don't get the possibility of a leak with perhaps some databases -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3008) Upgrade to Tomcat 9.0

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3008?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-3008. --------------------------- > Upgrade to Tomcat 9.0 > --------------------- > > Key: JBTM-3008 > URL: https://issues.jboss.org/browse/JBTM-3008 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Tom Jenkinson > Fix For: 5.8.2.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

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

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-3020: ---------------------------- Fix Version/s: 5.next (was: 5.8.2.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: 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)

5 years, 12 months

1
0
0 / 0

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

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3019?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-3019: ---------------------------- Fix Version/s: 5.next (was: 5.8.2.Final) > 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)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store.

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-3017: ---------------------------- Fix Version/s: 5.next (was: 5.8.2.Final) > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3010) Move the tomcat-jta module out of the narayana repo

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3010?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-3010: ---------------------------- Fix Version/s: 5.next (was: 5.8.2.Final) > Move the tomcat-jta module out of the narayana repo > --------------------------------------------------- > > Key: JBTM-3010 > URL: https://issues.jboss.org/browse/JBTM-3010 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > We tend to prefer the integration code for specific application servers be kept outside of the main Narayana transaction manager repository as it tends to iterate under different release cycle also. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3024) Make sure top level README says how to build the eclipse microprofile-lra artifacts

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3024?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-3024. --------------------------- > Make sure top level README says how to build the eclipse microprofile-lra artifacts > ----------------------------------------------------------------------------------- > > Key: JBTM-3024 > URL: https://issues.jboss.org/browse/JBTM-3024 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.8.2.Final > > > The lra subsystem depends on the microprofile-lra artifacts which are in a separate repo. build.sh and build.bat need build these dependencies. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3022) The build should build the (deprecated) lra-annotations module

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3022?page=com.atlassian.jira.plugin.... ] Amos Feng closed JBTM-3022. --------------------------- > The build should build the (deprecated) lra-annotations module > -------------------------------------------------------------- > > Key: JBTM-3022 > URL: https://issues.jboss.org/browse/JBTM-3022 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.8.2.Final > > > the lra parent pom should include a build of the lra-annotations module: > <module>lra-annotations</module> -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 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