September 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3075) Segment fault failure with tpacall when running the blacktie with centos7

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3075?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3075: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.Final) > Segment fault failure with tpacall when running the blacktie with centos7 > ------------------------------------------------------------------------- > > Key: JBTM-3075 > URL: https://issues.jboss.org/browse/JBTM-3075 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.9.0.Final > Environment: > you may get it by "uname -a" ? > Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux > >what is the version of the gcc, you could get by "gcc --version" > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) > rpm -qa | grep -i apr > apr-1.4.8-3.el7.x86_64 > apr-util-1.5.2-6.el7.x86_64 > Reporter: Zheng Feng > Priority: Major > Fix For: 5.next > > > The call stack is > {code} > #0 0x00007ffff607d9f6 in _int_malloc () from /usr/lib64/libc.so.6 > #1 0x00007ffff608010c in malloc () from /usr/lib64/libc.so.6 > #2 0x00007ffff5bc3263 in allocator_alloc (in_size=<optimized out>, > allocator=<optimized out>) at memory/unix/apr_pools.c:349 > #3 apr_pool_create_ex (newpool=0x7fffffff9cf0, parent=0x640b18, abort_fn=0x0, > allocator=0x63ca00) at memory/unix/apr_pools.c:891 > #4 0x00007ffff7ae9c6d in log4cxx::helpers::Pool::Pool (this=0x7fffffff9cf0) > at /home/hudson/blacktie/utils/apache-log4cxx/src/main/cpp/pool.cpp:34 > #5 0x00007ffff7b35eb0 in log4cxx::Logger::forcedLog (this=0x652bc0, > level1=..., message="HttpTxManager:57:ENTER HttpTxManager constructor", > location=...) > at /home/hudson/blacktie/utils/apache-log4cxx/src/main/cpp/logger.cpp:121 > #6 0x00007ffff74b655c in atmibroker::tx::HttpTxManager::HttpTxManager ( > this=0x6853a0, > txmUrl=0x714a60 "http://127.0.0.1:8080/rest-at-coordinator/tx/transaction-manager", resUrl=0x6ef560 "127.0.0.1:8888", __in_chrg=<optimized out>, > __vtt_parm=<optimized out>) > at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/HttpTxManager.cxx:57 > #7 0x00007ffff74b71ea in atmibroker::tx::HttpTxManager::create (txmUrl=0x714a60 "http://127.0.0.1:8080/rest-at-coordinator/tx/transaction-ma nager", resUrl=0x6ef560 "127.0.0.1:8888") > at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/HttpTxM---Type <return> to continue, or q <return> to quit--- > anager.cxx:87 > #8 0x00007ffff74a2c3e in atmibroker::tx::TxManager::get_instance () at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/TxManager.cxx:49 > #9 0x00007ffff74b5255 in txx_get_control () at /home/jenkins/workspace/release-narayana/blacktie/tx/src/main/cpp/TxManagerc.cxx:56 > #10 0x00007ffff72424c0 in tpacall (svc=0x42eb8c "some service", idata=0x69ab20 "N", ilen=0, flags=34) > {code} > The failure looks like related to the log4xx. -- This message was sent by Atlassian Jira (v7.13.5#713005)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3073) Do not mandate JAX-RS annotations on @Compensate/@Complete methods

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3073?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3073: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.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.13.5#713005)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3071) Windows automation of the LRA examples quickstarts

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3071?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3071: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.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.13.5#713005)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3046: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.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.13.5#713005)

5 years, 2 months

1
0
0 / 0

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

by Thomas Jenkinson (Jira)

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

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2998) Blacktie TestTPGetRply failed with unknown session

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2998?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-2998: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.Final) > Blacktie TestTPGetRply failed with unknown session > -------------------------------------------------- > > Key: JBTM-2998 > URL: https://issues.jboss.org/browse/JBTM-2998 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Zheng Feng > Priority: Minor > Fix For: 5.next > > Attachments: archive(1).zip, archive.zip > > > {noformat} > 2018-01-09 02:24:48,064 [0x00001db8] DEBUG (AtmiBrokerClient :200 ) - get session: 3 > 2018-01-09 02:24:48,064 [0x00001db8] DEBUG (AtmiBrokerClient :209 ) - did not get session: 3 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :411 ) - _get_tperrno > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :415 ) - found _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :418 ) - returning _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :924 ) - tpgetrply return: -1 tperrno: 2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :411 ) - _get_tperrno > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :415 ) - found _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :418 ) - returning _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] DEBUG (AtmiBrokerLogc :72 ) - CHKCOND ASSERT FAILED C:\hudson\workspace\narayana-catelyn\blacktie\xatmi\src\test\cpp\TestTPGetRply.cxx:272 > {noformat} > It looks like that the sessionIds have the prev id in the other tests which has not been removed. -- This message was sent by Atlassian Jira (v7.13.5#713005)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3181) lra-proxy-api is not deployed to Nexus during release

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3181?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3181: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.Final) > lra-proxy-api is not deployed to Nexus during release > ----------------------------------------------------- > > Key: JBTM-3181 > URL: https://issues.jboss.org/browse/JBTM-3181 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.7.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > Artifact `lra-proxy-api` is not (and it has never been) deployed at Nexus. -- This message was sent by Atlassian Jira (v7.13.5#713005)

5 years, 2 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 September 2019