May 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3302) New PR job text should include our policy on running checkstyle

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3302?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3302. ---------------------------------- > New PR job text should include our policy on running checkstyle > --------------------------------------------------------------- > > Key: JBTM-3302 > URL: https://issues.redhat.com/browse/JBTM-3302 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Build System > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.10.5.Final > > > The PR text should include the following: > {quote} > Our style rules for submitting code are as follows: > > * If you add a new file it MUST adhere to our checkstyle ruleset. > * If you change a file (in a non trivial way) you are allowed (MAY) to reformat the code to conform to our checkstyle ruleset. If you choose not to reformat it then you SHOULD, where possible, try to follow the same style that's already in use for that file. > Checkstyle is enabled via a boolean property "-Dcheckstyle" to the compilation. > {quote} > Note that we need our own property because you cannot override a plugin property that is already set in the plugin configuration section (ie -Dcheckstyle.skip=false does not work). The fix for this issue should include our new -Dcheckstyle property . -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

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

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3276) add SlotStore ObjectStore implementation

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3276?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3276. ---------------------------------- > add SlotStore ObjectStore implementation > ---------------------------------------- > > Key: JBTM-3276 > URL: https://issues.redhat.com/browse/JBTM-3276 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 5.10.3.Final > Reporter: Jonathan Halliday > Assignee: Jonathan Halliday > Priority: Minor > Fix For: 5.10.5.Final > > > The SlotStore provides an alternative ObjectStore implementation that dispenses with the file create/open/close/delete overhead of the FileStore, whilst also eschewing the write batching of the JournalStore. This combination is particularly tailored to new persistent memory hardware, for which the file write sync operation can be done in userspace with low overhead and a high degree of parallelism. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3258) Add checkstyle rules to the narayana performance repo

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3258?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3258. ---------------------------------- > Add checkstyle rules to the narayana performance repo > ----------------------------------------------------- > > Key: JBTM-3258 > URL: https://issues.redhat.com/browse/JBTM-3258 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Performance Testing > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.10.5.Final > > > We use [checkstyle|https://checkstyle.sourceforge.io] on the narayana repo (https://github.com/jbosstm/narayana/blob/master/pom.xml#L368). To maintain consistency we need add and use the same rule set for the [narayana performance repo|https://github.com/jbosstm/performance/tree/master/narayana]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3306) Quickstart jca-and-tomcat with JDK11, missing some maven dependencies

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3306?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3306. ---------------------------------- > Quickstart jca-and-tomcat with JDK11, missing some maven dependencies > --------------------------------------------------------------------- > > Key: JBTM-3306 > URL: https://issues.redhat.com/browse/JBTM-3306 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.10.4.Final > Reporter: Mayank Kunwar > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.10.5.Final > > > While running Quickstart jca-and-tomcat with JDK11 end up throwing below exception: > com.github.fungal.spi.deployers.DeployException: Deployment jar:file:/home/user/.m2/repository/org/jboss/ironjacamar/ironjacamar-embedded/1.1.0.Beta5/ironjacamar-embedded-1.1.0.Beta5.jar!/stdio.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:123) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > 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) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean JBossStdioService > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.lang.IllegalStateException: Already installed > at org.jboss.stdio.StdioContext.install(StdioContext.java:142) > at org.jboss.stdio.StdioService.start(StdioService.java:34) > 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 com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:428) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.042 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > 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)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3247. ---------------------------------- > Failed LRA records are reported but they not kept > ------------------------------------------------- > > Key: JBTM-3247 > URL: https://issues.redhat.com/browse/JBTM-3247 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.10.5.Final > > > When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. > It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3280) Some LRA TCK tests fail on CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3280?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3280. ---------------------------------- > Some LRA TCK tests fail on CI > ----------------------------- > > Key: JBTM-3280 > URL: https://issues.redhat.com/browse/JBTM-3280 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Martin Stefanko > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.10.5.Final > > > Not reproducible locally so far. > Currently we know of: > - TckTests#timeLimit > - -TckRecoveryTests#testCancelWhenParticipantIsRestarted- -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3293) LRA coordinator jar cannot be deployed on WildFly

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3293. ---------------------------------- > LRA coordinator jar cannot be deployed on WildFly > ------------------------------------------------- > > Key: JBTM-3293 > URL: https://issues.redhat.com/browse/JBTM-3293 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.10.5.Final > > > I am not sure whether this should be possible but the lra-coordinator.jar from lra-coordinator-jar module can't be deployed on latest WildFly. The deployment fails with the following error: > {noformat} > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAService with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService > at io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService(RecoveryCoordinator.java:0) > WELD-001474: Class io.narayana.lra.coordinator.domain.service.LRAService is on the classpath, but was ignored because a class it references was not found: com.arjuna.ats.arjuna.recovery.RecoveryModule from [Module "deployment.lra-coordinator.jar" from Service Module Loader]. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3313) FailedLRAIT tests in basic testsuite fail

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3313?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3313. ---------------------------------- > FailedLRAIT tests in basic testsuite fail > ----------------------------------------- > > Key: JBTM-3313 > URL: https://issues.redhat.com/browse/JBTM-3313 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.10.5.Final > > > {code:java} > [ERROR] Failures: > [ERROR] FailedLRAIT.testCompensateFailed:134 lra not in failed list > [ERROR] FailedLRAIT.testCompleteFailed:147 lra not in failed list > [ERROR] FailedLRAIT.testWithStatusCompensateFailed:106 lra not in failed list > [ERROR] FailedLRAIT.testWithStatusCompleteFailed:121 lra not in failed list > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3246) Support MP transaction context propagation for async calls for CDI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3246?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed JBTM-3246. ---------------------------------- > Support MP transaction context propagation for async calls for CDI > ------------------------------------------------------------------ > > Key: JBTM-3246 > URL: https://issues.redhat.com/browse/JBTM-3246 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.10.5.Final > > > For full integration of Narayana CDI handling to MicroProfile context propagation it needed to support context propagation for asynchronous calls. > Currently asynchronous call is handled just synchronously. That means the transaction is finished just at time when CDI interceptor finishes with the business method. While there could be some unfinished async call running aside of the main method. The async then may work with already finished transactions which lead to an error. > Here we aim to integrate with MicroProfile Smallrye implementation. The approach will be adapted from Quarkus. The point is to delay finishing of the transaction up to time the async method is finished as well. > The Quarkus code for this here: > https://github.com/quarkusio/quarkus/pull/2321/files#diff-9fae5ceb58cc73d... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 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 May 2020