July 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3029) SpecIT.timeLimitRequiredLRA failed on Mac CI

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-3029?page=com.atlassian.jira.plugin.... ] Michael Musgrove resolved JBTM-3029. ------------------------------------ Resolution: Duplicate Resolved as a side effect of fixing JBTM-3041 > SpecIT.timeLimitRequiredLRA failed on Mac CI > -------------------------------------------- > > Key: JBTM-3029 > URL: https://issues.jboss.org/browse/JBTM-3029 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Failed on CI run http://172.17.130.4:8083/job/narayana-mac/PROFILE=MAIN,jdk=jdk8.latest,la... > The test does a timed wait on a condition which eventually times out. The test may just need tweaking or alternatively a more sophisticated test may be required. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: (was: 5.next) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send()

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: (was: 5.next) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d18...] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2913. ------------------------------- Resolution: Done > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2110: -------------------------------- Status: Open (was: Pull Request Sent) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1107: -------------------------------- Status: Open (was: Pull Request Sent) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 5.later > > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 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: -------------------------------- Status: Open (was: Pull Request Sent) > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3009) Add the Transactional datasource factory in the tomcat-jta

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3009?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3009: -------------------------------- Fix Version/s: 5.8.2.Final (was: 5.next) > Add the Transactional datasource factory in the tomcat-jta > ---------------------------------------------------------- > > Key: JBTM-3009 > URL: https://issues.jboss.org/browse/JBTM-3009 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.8.2.Final > > > This factory is used to create the datasource with the common-dbcp2 and support XA and pooling, -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3009) Add the Transactional datasource factory in the tomcat-jta

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-3009?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-3009. ------------------------------- Resolution: Done > Add the Transactional datasource factory in the tomcat-jta > ---------------------------------------------------------- > > Key: JBTM-3009 > URL: https://issues.jboss.org/browse/JBTM-3009 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.8.2.Final > > > This factory is used to create the datasource with the common-dbcp2 and support XA and pooling, -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2913: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 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 July 2018