[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, 3 months
[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, 3 months
[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, 3 months
[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, 3 months