October 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2832) Blacktie TestTPGetRely::test_tpgetrply_with_TPGETANY fail

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2832?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2832: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > Blacktie TestTPGetRely::test_tpgetrply_with_TPGETANY fail > --------------------------------------------------------- > > Key: JBTM-2832 > URL: https://issues.jboss.org/browse/JBTM-2832 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Zheng Feng > Priority: Minor > Fix For: 5.next > > Attachments: CIfailure.zip > > > [exec] 1) test: TestTPGetRply::test_tpgetrply_with_TPGETANY (F) line: 272 C:\hudson\workspace\narayana-catelyn\blacktie\xatmi\src\test\cpp\TestTPGetRply.cxx > [exec] assertion failed > [exec] - Expression: _w12pq_u > [exec] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3141) Verify that LRA logs a warning when participant status does not match the expected outcome

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3141?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3141: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > Verify that LRA logs a warning when participant status does not match the expected outcome > ------------------------------------------------------------------------------------------ > > Key: JBTM-3141 > URL: https://issues.jboss.org/browse/JBTM-3141 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If participants are unable to compensate the implementation should log a warning (and similarly for complete). Check that the implementation does this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3073?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3073: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.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.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3137) Too much variance in the performance PR checker

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3137?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3137: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > Too much variance in the performance PR checker > ----------------------------------------------- > > Key: JBTM-3137 > URL: https://issues.jboss.org/browse/JBTM-3137 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The PERF axis of the PR checker job runs some tests to validate that the PR does not introduce any regressions but the axis is not useful since there is too much variance in the runs. For example PR https://github.com/jbosstm/narayana/pull/1437 ran 3 times each producing wildly different results. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3103) LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3103?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3103: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes > -------------------------------------------------------------------------------- > > Key: JBTM-3103 > URL: https://issues.jboss.org/browse/JBTM-3103 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > This quickstart depends on LRAParticipantDeserializer to recreate participants during crash recovery but [MP LRA issue #61|https://github.com/eclipse/microprofile-lra/issues/61] has removed this class. The alternative registration mechanism is still outstanding [see the comments on issue #35|https://github.com/eclipse/microprofile-lra/issues/35] for a discussion of the new way of registering participants. > Until a PR is raised for this issue I would like to disable the quickstarts that utilise LRAParticipantDeserializer. > Note that this has only just become an issue since previouslythe Narayana implementation of LRA depended on a specific snapshot build in the eclipse repo (since the LRA spec is in flux), but snapshots are purged after a month so the old way of registering participants is no longer available. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3108) Renable the maven site plugin for the LRA module

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3108?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3108: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > Renable the maven site plugin for the LRA module > ------------------------------------------------ > > Key: JBTM-3108 > URL: https://issues.jboss.org/browse/JBTM-3108 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Issue https://issues.jboss.org/browse/JBTM-3093 disabled the site plugin while the MP LRA APIs are still being developed. When MP LRA releases we need to renable the site plugin (used for code coverage tests). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3046: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.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.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3089) LRA code improvements

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3089?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3089: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > LRA code improvements > --------------------- > > Key: JBTM-3089 > URL: https://issues.jboss.org/browse/JBTM-3089 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Remove TODO comments from the code and replace with JIRA issues. > Ensure that the message string in all occurrences of GenericLRAException are meaningful. > Remove all commented out pieces of code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3075?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3075: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.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.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3102) Provide a gRPC service for accessing OTS funtionality

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3102?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3102: ----------------------------------- Fix Version/s: 5.next (was: 5.10.0.Final) > Provide a gRPC service for accessing OTS funtionality > ----------------------------------------------------- > > Key: JBTM-3102 > URL: https://issues.jboss.org/browse/JBTM-3102 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > JTS was the Java EE standard for different JTA implementations to interoperate. Since CORBA (and therefore JTS) is now an optional component of Jakarta EE there is a need for an alternative specification for how services can propagate a transaction context. A popular alternative to CORBA is gRPC which has the following nice features: 1) it is a good technology choice for service to service interactions; 2) is polyglot or, as stated in the documentation, "Automatically generates idiomatic client and server stubs for your service in a variety of languages and platforms"; and 3) provides excellent performance. > The reason JTS was chosen as the Java EE interop standard is that 1) it provides language level bindings that enable interoperability; and 2) it builds on a pre-existing industry standard, namely OTS. > Consequently, it is reasonable to conclude that a mapping from CosTransactions.idl (the IDL definition for OTS) to Protocol Buffers and gRPC services will: > - Enable existing OTS/JTS implementations to provide service in these new environments. > - Enable new and existing gRPC services to be able to access transactional functionality in an interoperable manner. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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 October 2019