March 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3263) Quickstart ArjunaJTS/interop works only on Narayana CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3263?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3263: ----------------------------------- Fix Version/s: 5.next > Quickstart ArjunaJTS/interop works only on Narayana CI > ------------------------------------------------------ > > Key: JBTM-3263 > URL: https://issues.redhat.com/browse/JBTM-3263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > The Narayana quickstart `ArjunaJTS/interop` works only on Narayana CI. > (https://github.com/jbosstm/quickstart/tree/5.10.4.Final/ArjunaJTS/interop) > Otherwise it fails with > {code} > + svn checkout https://svn.java.net/svn/glassfish~svn/trunk/main /tmp/ArjunaJTS/interop/glassfish/tmp/glassfish4 > svn: E170011: Repository moved temporarily to 'http://www.oracle.com/splash/java.net/maintenance/index.html' > [ERROR] Command execution failed. > org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1) > at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404) > at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166) > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804) > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751) > at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3267) Narayana quickstarts should be possible to be compiled without need to define any specific env variable needed for testing

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3267?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3267: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Narayana quickstarts should be possible to be compiled without need to define any specific env variable needed for testing > -------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3267 > URL: https://issues.redhat.com/browse/JBTM-3267 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > When Narayana quickstarts is run with {{mvn install -DskipTests` it fails as it requires (at least) {{JBOSS_HOME}} env variable to be set. When the quickstart are about to be just installed and not running then it should not be necessary to pre-define any variable. > All quickstarts should be just compiled. > And then it's possible to go to particular quickstart folder and set necessary env variable and run the tests. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3263) Quickstart ArjunaJTS/interop works only on Narayana CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3263?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3263: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Quickstart ArjunaJTS/interop works only on Narayana CI > ------------------------------------------------------ > > Key: JBTM-3263 > URL: https://issues.redhat.com/browse/JBTM-3263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > The Narayana quickstart `ArjunaJTS/interop` works only on Narayana CI. > (https://github.com/jbosstm/quickstart/tree/5.10.4.Final/ArjunaJTS/interop) > Otherwise it fails with > {code} > + svn checkout https://svn.java.net/svn/glassfish~svn/trunk/main /tmp/ArjunaJTS/interop/glassfish/tmp/glassfish4 > svn: E170011: Repository moved temporarily to 'http://www.oracle.com/splash/java.net/maintenance/index.html' > [ERROR] Command execution failed. > org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1) > at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404) > at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166) > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804) > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751) > at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3260) On publishing a new Narayana release there should be created Quarkus PR to update Narayana version

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3260?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3260: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jbosstm/narayana/pull/1569 > On publishing a new Narayana release there should be created Quarkus PR to update Narayana version > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3260 > URL: https://issues.redhat.com/browse/JBTM-3260 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > As currently when a Narayana minor release is published it's usual to create a WildFly pull request which updates the Narayana version to the most up-to-date. > This functionality is automatized in the release script: > https://github.com/jbosstm/narayana/blob/5.10.4.Final/narayana-release-pr... > It would be good to have a similar functionality for the Quarkus. Narayana is the component managing JTA trasaction there and it would be good to pass there the newest version as well. > Narayana version could be updated at: > https://github.com/quarkusio/quarkus/blob/1.2.1.Final/bom/runtime/pom.xml... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3260) On publishing a new Narayana release there should be created Quarkus PR to update Narayana version

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3260?page=com.atlassian.jira.plugin... ] Work on JBTM-3260 started by Mayank Kunwar. ------------------------------------------- > On publishing a new Narayana release there should be created Quarkus PR to update Narayana version > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3260 > URL: https://issues.redhat.com/browse/JBTM-3260 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > As currently when a Narayana minor release is published it's usual to create a WildFly pull request which updates the Narayana version to the most up-to-date. > This functionality is automatized in the release script: > https://github.com/jbosstm/narayana/blob/5.10.4.Final/narayana-release-pr... > It would be good to have a similar functionality for the Quarkus. Narayana is the component managing JTA trasaction there and it would be good to pass there the newest version as well. > Narayana version could be updated at: > https://github.com/quarkusio/quarkus/blob/1.2.1.Final/bom/runtime/pom.xml... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3249) XA_RB* exception at prepare incorrectly still calls rollback.

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3249?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Michael Musgrove created pull request #1568 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > XA_RB* exception at prepare incorrectly still calls rollback. > ------------------------------------------------------------- > > Key: JBTM-3249 > URL: https://issues.redhat.com/browse/JBTM-3249 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.10.3.Final > Reporter: Jonathan Halliday > Assignee: Michael Musgrove > Priority: Major > > XAResourceRecord.topLevelPrepare maps XA_RB* codes as PREPARE_NOTOK, which causes ArjunaCore to re-queue the record on the pending list and subsequently call topLevelAbort. This is incorrect from an XA spec perspective, as XA_RB at prepare indicates the RM has terminated and forgotten the tx, so a rollback thereafter may causes unexpected problems. > Whereas the elegant fix is probably a new TwoPhaseOutcome to distinguish 'NOTOK, don't call me again' from 'NOTOK, roll me back', that's a bit of a pain. The alternative is to leverage the mechanism we already have for employing this optimization in cases where we can, and extend it to cases where we should. > {code:java} > switch (e1.errorCode) { > case XAException.XA_RBROLLBACK: > case XAException.XA_RBEND: > case XAException.XA_RBCOMMFAIL: > case XAException.XA_RBDEADLOCK: > case XAException.XA_RBINTEGRITY: > case XAException.XA_RBOTHER: > case XAException.XA_RBPROTO: > case XAException.XA_RBTIMEOUT: > // we may want to pull XAER_NOTA up here too? > if (_theTransaction != null) { > _theTransaction.setXAResourceState(_theXAResource, TxInfo.OPTIMIZED_ROLLBACK); > // in a perfect word we'd call removeConnection here, but we probably need to do in in topLevelAbort instead, unless we change its implementation > } > // now fall through... > case XAException.XAER_RMERR: > case XAException.XAER_RMFAIL: > case XAException.XAER_INVAL: > case XAException.XAER_PROTO: > case XAException.XAER_NOTA: // resource may have arbitrarily rolled back (shouldn't, but ...) > return TwoPhaseOutcome.PREPARE_NOTOK; // will not call rollback [*cough*bullshit*cough*] > default: > return TwoPhaseOutcome.HEURISTIC_HAZARD; // we're not really sure (shouldn't get here though). > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3262) improve string serialization

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3262?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3262: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > improve string serialization > ---------------------------- > > Key: JBTM-3262 > URL: https://issues.redhat.com/browse/JBTM-3262 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.10.3.Final > Reporter: Jonathan Halliday > Assignee: Jonathan Halliday > Priority: Minor > Fix For: 5.next > > > Core's handling of unicode string packing is, not to put too fine a point on it, wrong. > OutputBuffer's packString(String s) assumes the serialized form of a UTF-8 string has the same number of bytes as the String has code units, which is incorrect for any String containing multi-byte code units. > Since that needs fixing anyhow, the refactoring pulls out the byte[] packing to a separate function from the String encoding, additionally enabling a performance optimization: > Where a fixed String is packed frequently, the transformation to byte[] can be done once and cached, eliding memory allocation and processing on subsequent invocations. This is particularly useful for the StateManager marker, which is packed to buffers with great frequency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3249) XA_RB* exception at prepare incorrectly still calls rollback.

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3249?page=com.atlassian.jira.plugin... ] Michael Musgrove reassigned JBTM-3249: -------------------------------------- Assignee: Michael Musgrove > XA_RB* exception at prepare incorrectly still calls rollback. > ------------------------------------------------------------- > > Key: JBTM-3249 > URL: https://issues.redhat.com/browse/JBTM-3249 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.10.3.Final > Reporter: Jonathan Halliday > Assignee: Michael Musgrove > Priority: Major > > XAResourceRecord.topLevelPrepare maps XA_RB* codes as PREPARE_NOTOK, which causes ArjunaCore to re-queue the record on the pending list and subsequently call topLevelAbort. This is incorrect from an XA spec perspective, as XA_RB at prepare indicates the RM has terminated and forgotten the tx, so a rollback thereafter may causes unexpected problems. > Whereas the elegant fix is probably a new TwoPhaseOutcome to distinguish 'NOTOK, don't call me again' from 'NOTOK, roll me back', that's a bit of a pain. The alternative is to leverage the mechanism we already have for employing this optimization in cases where we can, and extend it to cases where we should. > {code:java} > switch (e1.errorCode) { > case XAException.XA_RBROLLBACK: > case XAException.XA_RBEND: > case XAException.XA_RBCOMMFAIL: > case XAException.XA_RBDEADLOCK: > case XAException.XA_RBINTEGRITY: > case XAException.XA_RBOTHER: > case XAException.XA_RBPROTO: > case XAException.XA_RBTIMEOUT: > // we may want to pull XAER_NOTA up here too? > if (_theTransaction != null) { > _theTransaction.setXAResourceState(_theXAResource, TxInfo.OPTIMIZED_ROLLBACK); > // in a perfect word we'd call removeConnection here, but we probably need to do in in topLevelAbort instead, unless we change its implementation > } > // now fall through... > case XAException.XAER_RMERR: > case XAException.XAER_RMFAIL: > case XAException.XAER_INVAL: > case XAException.XAER_PROTO: > case XAException.XAER_NOTA: // resource may have arbitrarily rolled back (shouldn't, but ...) > return TwoPhaseOutcome.PREPARE_NOTOK; // will not call rollback [*cough*bullshit*cough*] > default: > return TwoPhaseOutcome.HEURISTIC_HAZARD; // we're not really sure (shouldn't get here though). > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3260) On publishing a new Narayana release there should be created Quarkus PR to update Narayana version

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3260?page=com.atlassian.jira.plugin... ] Mayank Kunwar reassigned JBTM-3260: ----------------------------------- Assignee: Mayank Kunwar (was: Ondrej Chaloupka) > On publishing a new Narayana release there should be created Quarkus PR to update Narayana version > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3260 > URL: https://issues.redhat.com/browse/JBTM-3260 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > As currently when a Narayana minor release is published it's usual to create a WildFly pull request which updates the Narayana version to the most up-to-date. > This functionality is automatized in the release script: > https://github.com/jbosstm/narayana/blob/5.10.4.Final/narayana-release-pr... > It would be good to have a similar functionality for the Quarkus. Narayana is the component managing JTA trasaction there and it would be good to pass there the newest version as well. > Narayana version could be updated at: > https://github.com/quarkusio/quarkus/blob/1.2.1.Final/bom/runtime/pom.xml... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3268) Narayana can't be built on JDK9

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3268?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3268: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Narayana can't be built on JDK9 > ------------------------------- > > Key: JBTM-3268 > URL: https://issues.redhat.com/browse/JBTM-3268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, LRA, XTS > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > Narayana cannot be built on JDK9. > The failure happens at module: {{ArjunaJTS/orbportability}} > and the error is > {quote} > Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.0:compile (jacorb-compile) on project orbportability: Fatal error compiling: option --add-modules not allowed with target 1.8 > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2020