April 2020 - jbossts-issues - Jboss List Archives

[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 updated JBTM-3280: ----------------------------------- Description: Not reproducible locally so far. Currently we know of: - TckTests#timeLimit - ~TckRecoveryTests#testCancelWhenParticipantIsRestarted~ was: Not reproducible locally so far. Currently we know of: - TckTests#timeLimit - TckRecoveryTests#testCancelWhenParticipantIsRestarted > 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: Martin Stefanko > Priority: Major > > Not reproducible locally so far. > Currently we know of: > - TckTests#timeLimit > - ~TckRecoveryTests#testCancelWhenParticipantIsRestarted~ -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3283) LRA TckRecoveryTests used with -Dit.test fails with IllegalArgumentException: Cannot parse java VM arguments

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3283?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3283: ---------------------------------------- I found that main trouble of the parsing `javaVmArguments` inside of the `arquillian-throntail.xml` is the version of the thorntail. With reducing space it makes the arquillian to start but the arguments could not be correctly passed to the runtime. E.g. debug parameters were not working at all. With changing to 2.6.0.Final the issue seems to be fixed. The parsing of the spaces are fine now. > LRA TckRecoveryTests used with -Dit.test fails with IllegalArgumentException: Cannot parse java VM arguments > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3283 > URL: https://issues.redhat.com/browse/JBTM-3283 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > When the LRA TCK is run with {{-Dit.test}} e.g. {{mvn clean verify -Parq -Dit.test=TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} then it fails with > {code} > ava.lang.RuntimeException: Could not create statement > Caused by: java.lang.RuntimeException: Could not lookup value for field private java.net.URL org.eclipse.microprofile.lra.tck.TckRecoveryTests.deploymentURL > Caused by: java.lang.IllegalArgumentException: Cannot parse java VM arguments -Dthorntail.http.host=localhost -Dthorntail.http.port=8180 -Dlra.tck.coordinator.hostname=localhost -Dlra.tck.coordinator.port=8080 -Dlra.http.host=localhost -Dlra.http.port=8080 -Dlra.tck.consistency.shortDelay=1000 -Dlra.tck.consistency.longDelay=20000 > {code} > The trouble is that Arquillian (in particular it could be the Thorntail Arquillian adapter) is not capable to parse multiple spaces in the VM args. > https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/lra/lra-test/lr... > Ie. in the stup there could happen to be resolved to > {code} > <property name="javaVmArguments">{space}{space}{space}{space}-Dthorntail.http.host=localhost ... > {code} > Those multiple spaces seems to do some troubles -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3284) TckRecoveryTests are failing

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3284: ------------------------------------- Summary: TckRecoveryTests are failing Key: JBTM-3284 URL: https://issues.redhat.com/browse/JBTM-3284 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.4.Final Reporter: Martin Stefanko Assignee: Martin Stefanko TckRecoveryTests are failing with several issues. Also will require some fixes in the TCK. {noformat} [INFO] [lra-coordinator-it-test] Caused by: java.lang.NullPointerException [INFO] [lra-coordinator-it-test] at io.narayana.lra.coordinator.domain.model.LRARecord.atEnd(LRARecord.java:443) {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3283) LRA TckRecoveryTests used with -Dit.test fails with IllegalArgumentException: Cannot parse java VM arguments

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3283?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3283: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1594 > LRA TckRecoveryTests used with -Dit.test fails with IllegalArgumentException: Cannot parse java VM arguments > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3283 > URL: https://issues.redhat.com/browse/JBTM-3283 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > When the LRA TCK is run with {{-Dit.test}} e.g. {{mvn clean verify -Parq -Dit.test=TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} then it fails with > {code} > ava.lang.RuntimeException: Could not create statement > Caused by: java.lang.RuntimeException: Could not lookup value for field private java.net.URL org.eclipse.microprofile.lra.tck.TckRecoveryTests.deploymentURL > Caused by: java.lang.IllegalArgumentException: Cannot parse java VM arguments -Dthorntail.http.host=localhost -Dthorntail.http.port=8180 -Dlra.tck.coordinator.hostname=localhost -Dlra.tck.coordinator.port=8080 -Dlra.http.host=localhost -Dlra.http.port=8080 -Dlra.tck.consistency.shortDelay=1000 -Dlra.tck.consistency.longDelay=20000 > {code} > The trouble is that Arquillian (in particular it could be the Thorntail Arquillian adapter) is not capable to parse multiple spaces in the VM args. > https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/lra/lra-test/lr... > Ie. in the stup there could happen to be resolved to > {code} > <property name="javaVmArguments">{space}{space}{space}{space}-Dthorntail.http.host=localhost ... > {code} > Those multiple spaces seems to do some troubles -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 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 updated JBTM-3280: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1594 > 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: Martin Stefanko > Priority: Major > > Not reproducible locally so far. > Currently we know of: > - TckTests#timeLimit > - TckRecoveryTests#testCancelWhenParticipantIsRestarted -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3283) LRA TckRecoveryTests used with -Dit.test fails with IllegalArgumentException: Cannot parse java VM arguments

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3283: -------------------------------------- Summary: LRA TckRecoveryTests used with -Dit.test fails with IllegalArgumentException: Cannot parse java VM arguments Key: JBTM-3283 URL: https://issues.redhat.com/browse/JBTM-3283 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.4.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka When the LRA TCK is run with {{-Dit.test}} e.g. {{mvn clean verify -Parq -Dit.test=TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} then it fails with {code} ava.lang.RuntimeException: Could not create statement Caused by: java.lang.RuntimeException: Could not lookup value for field private java.net.URL org.eclipse.microprofile.lra.tck.TckRecoveryTests.deploymentURL Caused by: java.lang.IllegalArgumentException: Cannot parse java VM arguments -Dthorntail.http.host=localhost -Dthorntail.http.port=8180 -Dlra.tck.coordinator.hostname=localhost -Dlra.tck.coordinator.port=8080 -Dlra.http.host=localhost -Dlra.http.port=8080 -Dlra.tck.consistency.shortDelay=1000 -Dlra.tck.consistency.longDelay=20000 {code} The trouble is that Arquillian (in particular it could be the Thorntail Arquillian adapter) is not capable to parse multiple spaces in the VM args. https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/lra/lra-test/lr... Ie. in the stup there could happen to be resolved to {code} <property name="javaVmArguments">{space}{space}{space}{space}-Dthorntail.http.host=localhost ... {code} Those multiple spaces seems to do some troubles -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3271) javadoc error when building with JDK11

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3271?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3271: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1583 > javadoc error when building with JDK11 > -------------------------------------- > > Key: JBTM-3271 > URL: https://issues.redhat.com/browse/JBTM-3271 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > When we build using JDK11 we get javadoc errors. For example building ArjunaCore/arjunacore: > bq. javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module. > More context is here: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8212233 > A fix is to configure the javadoc plugin (org.apache.maven.plugins:maven-javadoc-plugin) to use <source>8</source> in the plugin configuration section. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3275) Quickstart XTS SSL quickstart may be stuck when container is not started at time

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3275?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3275: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Quickstart XTS SSL quickstart may be stuck when container is not started at time > -------------------------------------------------------------------------------- > > Key: JBTM-3275 > URL: https://issues.redhat.com/browse/JBTM-3275 > 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 > > > The quickstart XTS over SSL defines wrongly a way how the timeout to wait on container is done. When timeout happens it has to try to stop the container if it would be still in progress of starting. It's needed to be stopped first. > https://github.com/jbosstm/quickstart/blob/5.10.4.Final/XTS/ssl/xts-over-... > Otherwise exit is called but the server is hanging around and the job can't be stopped. > The script may be stuck like > {code} > INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server > INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management > INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090 > INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 20.0.0.Beta1-SNAPSHOT (WildFly Core 11.0.0.Final) started in 18797ms - Started 380 of 646 services (392 services are lazy, passive or on-demand) > "result" => "running" > + RETURN_CODE=0 > ++ date +%s > + '[' 24 -gt 20 ']' > + NOT_TIMEOUTED=false > + '[' 0 -ne 0 ']' > + false > + echo 'Timeout 20s exceeded when waiting for container at port 10090' > + exit 2 > Timeout 20s exceeded when waiting for container at port 10090 > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3270) Rollback of inbound REST-AT transaction causes warning message being printed under server.log

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3270?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3270: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Rollback of inbound REST-AT transaction causes warning message being printed under server.log > --------------------------------------------------------------------------------------------- > > Key: JBTM-3270 > URL: https://issues.redhat.com/browse/JBTM-3270 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > When a inbound REST-AT Transaction is rolled-back while it was not yet persisted into object store then a warning message is shown in the log > {quote} > [com.arjuna.ats.arjuna] (default task-2) ARJUNA012269: UNKNOWN state for object with uid 0:ffff0a00000a:1f1301f3:5e7de5f0:37 , type /REST-AT/Integration/ParticipantInformationRecoveryRecord > {quote} > The reason for this is that REST-AT {{RecoveryManager}} instance does not track which participants were really persisted ({{ObjectStore.write_committed}}). Regardless of this fact the removal is attempted and the underlaying removal found it knows nothing about such state > https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaCore/arjuna/c... > This should be probably handled similarly to the XTS bridge > https://github.com/jbosstm/narayana/blob/5.10.4.Final/XTS/recovery/src/or... > where {{uidMap}} is used to not issue removal of non-persisted items. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3158) jta-and-hibernate-standalone Narayana quickstart will not execute properly - EntityExistsException

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3158?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3158: ----------------------------------- Fix Version/s: 5.next > jta-and-hibernate-standalone Narayana quickstart will not execute properly - EntityExistsException > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3158 > URL: https://issues.redhat.com/browse/JBTM-3158 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Miloslav Žežulka > Assignee: Mayank Kunwar > Priority: Minor > Fix For: 5.next > > > One of the [Narayana quickstarts|https://github.com/jbosstm/quickstart] throws the following exception when executed according to the steps in README.md: > java.lang.reflect.InvocationTargetException > 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.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:293) > at java.lang.Thread.run (Thread.java:748) > Caused by: javax.persistence.EntityExistsException: A different object with the same identifier value was already associated with the session : [org.jboss.narayana.quickstart.jta.QuickstartEntity#1] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert (AbstractEntityManagerImpl.java:1664) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert (AbstractEntityManagerImpl.java:1602) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert (AbstractEntityManagerImpl.java:1608) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.persist (AbstractEntityManagerImpl.java:1152) > at org.jboss.narayana.quickstart.jta.QuickstartEntityRepository.save (QuickstartEntityRepository.java:45) > at org.jboss.narayana.quickstart.jta.QuickstartEntityRepository$Proxy$_$$_WeldSubclass.save$$super (Unknown Source) > 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.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal (TerminalAroundInvokeInvocationContext.java:49) > at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed (AroundInvokeInvocationContext.java:77) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx (TransactionalInterceptorBase.java:186) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept (TransactionalInterceptorRequired.java:55) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept (TransactionalInterceptorBase.java:88) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept (TransactionalInterceptorRequired.java:47) > 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.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke (SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke (InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception (InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke (InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke (CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke (CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at org.jboss.narayana.quickstart.jta.QuickstartEntityRepository$Proxy$_$$_WeldSubclass.save (Unknown Source) > at org.jboss.narayana.quickstart.jta.QuickstartService.executeDemonstration (QuickstartService.java:106) > at org.jboss.narayana.quickstart.jta.QuickstartService.demonstrateCommit (QuickstartService.java:55) > at org.jboss.narayana.quickstart.jta.QuickstartApplication.main (QuickstartApplication.java:78) > 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.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:293) > at java.lang.Thread.run (Thread.java:748) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2020