May 2020 - jbossts-issues - Jboss List Archives

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3262?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3262. ---------------------------------- > 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.10.5.Final > > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3239) Failing AfterLRA participant calls are not repeated with recovery module

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3239. ---------------------------------- > Failing AfterLRA participant calls are not repeated with recovery module > ------------------------------------------------------------------------ > > Key: JBTM-3239 > URL: https://issues.redhat.com/browse/JBTM-3239 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.10.5.Final > > > The afterLRA calls are currently delivered only twice when the LRA is finished (twice because of JBTM-3163). When these two calls fail the afterLRA call is never repeated again. However, the specification states that afterLRA must be repeated until the 200 status code is returned. > The main reason for this issue is the handling of afterLRA listeners in the Transaction object which means that the LRA enters the end phase (Closed/Cancelled) then the afterLRA listeners are called (twice because of above-mentioned issue) but if these calls fail there is nothing telling the transaction object to repeat the calls on the recovery. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3290) ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3290?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3290. ---------------------------------- > ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1 > ---------------------------------------------------------------------------- > > Key: JBTM-3290 > URL: https://issues.redhat.com/browse/JBTM-3290 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.10.5.Final > > Attachments: consoleText.zip > > > When our AMS CI is slower then the quickstart {{ArjunaJTS/interop/glassfish}} consistently fails with error > {code} > [0m[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:132) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3274) Narayana quickstarts can't be built on CI as IPv4 is not forced

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3274?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3274. ---------------------------------- > Narayana quickstarts can't be built on CI as IPv4 is not forced > --------------------------------------------------------------- > > Key: JBTM-3274 > URL: https://issues.redhat.com/browse/JBTM-3274 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.10.5.Final > > > Narayana quickstarts can't be built on new AMS NarayanaCi1 installation as the IP protocol is not defined on default. The exception to get is [1]. > This makes troubles especially for Thorntail when running with LRA quickstarts. > We need to define IPv4 as default when IPv6 is not expected. > This could be done with {{-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses}} > {quote} > MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:211) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:220) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:85) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:178) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:303) > at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:106) > at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:199) > ... 8 more > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3319) Use LRA microprofile version of 1.0-M1

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3319?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3319. ---------------------------------- > Use LRA microprofile version of 1.0-M1 > -------------------------------------- > > Key: JBTM-3319 > URL: https://issues.redhat.com/browse/JBTM-3319 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.10.5.Final > > > Using the nightbuild SNAPSHOT versions of the LRA microprofile spec as dependency in the Narayana code is unstable and as it disappears after some time from the Eclipse repository it's not possible to build Narayana from released tag. > The casual milestone release M1 is to be released to freeze the current state of the spec and for to be used in Narayana when it will be released. > See https://ci.eclipse.org/microprofile/job/MicroProfile%20Releases/378/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3315) RecoveryDriver should offer methods for verbose scan

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3315?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3315. ---------------------------------- > RecoveryDriver should offer methods for verbose scan > ---------------------------------------------------- > > Key: JBTM-3315 > URL: https://issues.redhat.com/browse/JBTM-3315 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.10.5.Final > > > It would be fine if the {{RecoveryDriver}} is enhanced with methods to scan verbosely. > https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaCore/arjuna/c... > Currently there are only methods {{synchronousScan}} and {{asynchronousScan}}. > The point is to add at least the two more {{synchronousVerboseScan}} and {{asynchronousVerboseScan}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3236?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3236. ---------------------------------- > 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.10.5.Final > > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3305) Quickstart transactionaldriver-standalone module throws an exception when build with JDK11

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3305?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3305. ---------------------------------- > Quickstart transactionaldriver-standalone module throws an exception when build with JDK11 > ------------------------------------------------------------------------------------------ > > Key: JBTM-3305 > URL: https://issues.redhat.com/browse/JBTM-3305 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Mayank Kunwar > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.10.5.Final > > > When running Quickstart transactionaldriver-standalone on JDK11 with below command throws exception. > mvn clean install > java.io.IOException: Can not attach to current VM > at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.<init>(HotSpotVirtualMachine.java:75) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:57) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > at org.jboss.byteman.agent.install.Install.attach(Install.java:451) > at org.jboss.byteman.agent.install.Install.install(Install.java:161) > at org.jboss.byteman.agent.install.Install.install(Install.java:116) > at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516) > at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3281) Forget should be called for nested participant when the parent LRA is closed

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3281?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3281. ---------------------------------- > Forget should be called for nested participant when the parent LRA is closed > ---------------------------------------------------------------------------- > > Key: JBTM-3281 > URL: https://issues.redhat.com/browse/JBTM-3281 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.10.5.Final > > > The TCK test {{TckContextTests.testForgetCalledForNestedParticipantsWhenParentIsClosed}} is currently failing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3294) Include a custom HTTP LRA version header on REST calls made by our implementation

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3294?page=com.atlassian.jira.plugin... ] Michael Musgrove reassigned JBTM-3294: -------------------------------------- Assignee: Ondrej Chaloupka (was: Michael Musgrove) > Include a custom HTTP LRA version header on REST calls made by our implementation > --------------------------------------------------------------------------------- > > Key: JBTM-3294 > URL: https://issues.redhat.com/browse/JBTM-3294 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Blocker > Fix For: 5.10.5.Final > > > Our implementation of the LRA specification exposes REST endpoints whose semantics may change over time. As the LRA spec evolves users will need a guarantee that the endpoints behave consistently. > To avoid introducing breaking changes I propose that we version REST API calls made by the implementation using a version header, something like: > bq. OpenStack-API-Version: narayana LRA 5.10.5.Final > or > bq. OpenStack-API-Version: narayana LRA 5.10.5.Final https://<the location of our OpenAPI document> > I went for the [OpenStack guideline|https://specs.openstack.org/openstack/api-wg/guidelines/headers...] since it was the only standard I could find for custom headers. > A reason it is narayana specific is that our API offers more than the spec requires. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2020