January 2020 - jbossts-issues - Jboss List Archives

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

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3073?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3073: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Do not mandate JAX-RS annotations on @Compensate/@Complete methods > ------------------------------------------------------------------ > > Key: JBTM-3073 > URL: https://issues.redhat.com/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)

4 years, 3 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.redhat.com/browse/JBTM-3075?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3075: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Segment fault failure with tpacall when running the blacktie with centos7 > ------------------------------------------------------------------------- > > Key: JBTM-3075 > URL: https://issues.redhat.com/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)

4 years, 3 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3102?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3102: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Provide a gRPC service for accessing OTS funtionality > ----------------------------------------------------- > > Key: JBTM-3102 > URL: https://issues.redhat.com/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)

4 years, 3 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3108?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3108: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Renable the maven site plugin for the LRA module > ------------------------------------------------ > > Key: JBTM-3108 > URL: https://issues.redhat.com/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)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3233) Port the JTA recovery quickstart to run with the Quarkus Narayana JTA extension

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3233?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3233: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Port the JTA recovery quickstart to run with the Quarkus Narayana JTA extension > ------------------------------------------------------------------------------- > > Key: JBTM-3233 > URL: https://issues.redhat.com/browse/JBTM-3233 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Quickstarts > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The [JTA recovery quickstart|https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/re...] with maven artefact id: org.jboss.narayana.quickstart.jta:recovery looks like it should run fine with the [Quarkus Narayana JTA extension|https://github.com/quarkusio/quarkus/tree/master/extensions/nar...]. > This task is to check what we need to do with the quickstart to run it with the extension. Maybe include it as one of the [Quarkus quickstart examples|https://github.com/quarkusio/quarkus-quickstarts]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3235) Performance regression tests should consult the "Score Error" before reporting regressions

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3235?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3235: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Performance regression tests should consult the "Score Error" before reporting regressions > ------------------------------------------------------------------------------------------ > > Key: JBTM-3235 > URL: https://issues.redhat.com/browse/JBTM-3235 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > We perform [microbenchmark performance testing of JTA|https://github.com/jbosstm/performance/tree/master/narayana/ArjunaJTA...] and we have Jenkins CI jobs (btny-pulls-performance and narayana-performance-version-comparison) that do regression testing against different versions of the product. > These tests use [JMH|https://openjdk.java.net/projects/code-tools/jmh/] to perform the test runs. The results of each run are reported as a CSV file in the following example format: > {code} > "Version","Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" > 5.5.32.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,217253.976024,8720.877211,"ops/s" > 5.9.0.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,216552.983213,6586.482104,"ops/s" > {code} > This example shows a comparison between versions 5.5.32.Final and 5.9.0.Final. The data shows that > we measured using a mode called "thrpt" (ie transactions per second or TPS) and the Score shows the TPS was 217253 vers > us 216552. There is also a Score Error which I understand indicates the upper and lower error bars for the measurement. > None of our jobs take account of the error bars when reporting regressions. What we need to do is look at the Score Error to see if the runs are within tolerance before reporting a regression. > An example of how to manually run a regression test is as follows: > {code} > git clone https://github.com/jbosstm/performance # clone the performance git repo > cd performance > export JMHARGS="-t 240 -r 30 -f 3 -wi 5 -i 5" # tune the test using JMH config params > # and then do a performance run: > export version=5.5.32.Final # set the target narayana version > ./build.sh -f narayana/ArjunaJTA/jta/pom.xml clean install -DskipTests -Dnarayana.version=$version > java -classpath narayana/ArjunaJTA/jta/target/classes/ -Dcom.arjuna.ats.arjuna.common.propertiesFile=jbossts-properties.xml -jar narayana/ArjunaJTA/jta/target/benchmarks.jar io.narayana.perf.product.NarayanaComparison.* $JMHARGS -rf csv -rff io.narayana.perf.product.NarayanaComparison-$version.csv > {code} > The results are in the named csv file. > Then do the same for the second version -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3241) Create a test to validate that the LRA coordinator getStatus query returns a state that matches the state model

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3241?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3241: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Create a test to validate that the LRA coordinator getStatus query returns a state that matches the state model > ---------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3241 > URL: https://issues.redhat.com/browse/JBTM-3241 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA coordinator acts as a participant when LRA's are nested. We need a test that validates that the correct participant states are reported in accordance with Figure 3. Participant State Model of the [LRA participant state model|https://github.com/eclipse/microprofile-lra/blob/master/spec/src/ma...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3236) Upgrade to latest byteman release

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3236?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3236: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Upgrade to latest byteman release > --------------------------------- > > Key: JBTM-3236 > URL: https://issues.redhat.com/browse/JBTM-3236 > Project: JBoss Transaction Manager > Issue Type: Quality Risk > Components: Testing > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > JBTM-3226 (Byteman rule check failure with version 4.0.9) introduced a byteman version change but the new version contained a bug which has now been fixed in 4.0.10 (see BYTEMAN-391) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3213) Ensure the LRA module is configurable

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3213?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3213: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Ensure the LRA module is configurable > -------------------------------------- > > Key: JBTM-3213 > URL: https://issues.redhat.com/browse/JBTM-3213 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > There are some LRA parameters that we would like to be configurable (timeouts and thread pools for example). Since LRA is a microprofile spec we should leverage microprofile-config for this purpose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3217) Take Compensate and Complete timeout information from the LRA annotation in the same class

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3217?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3217: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Take Compensate and Complete timeout information from the LRA annotation in the same class > ------------------------------------------------------------------------------------------ > > Key: JBTM-3217 > URL: https://issues.redhat.com/browse/JBTM-3217 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > Update the handling of timeout information for Compensate and Complete according to the specification. Now it's defined in the LRA annotation similarly as for the new LRA. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 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 January 2020