[JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+
by Mayank Kunwar (Jira)
[ https://issues.redhat.com/browse/JBTM-3122?page=com.atlassian.jira.plugin... ]
Mayank Kunwar commented on JBTM-3122:
-------------------------------------
Added a profile to parent pom.xml, which will define all the needful properties required for JDK9+ version.
> jbosstm/quickstarts tests can't be run with jdk9+
> -------------------------------------------------
>
> Key: JBTM-3122
> URL: https://issues.redhat.com/browse/JBTM-3122
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Build System
> Affects Versions: 5.9.3.Final
> Reporter: Ondrej Chaloupka
> Assignee: Mayank Kunwar
> Priority: Major
>
> Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more).
> The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}.
> See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188
> {code}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
> --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED
> --add-modules=java.se
> {code}
> The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts.
> Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+
by Mayank Kunwar (Jira)
[ https://issues.redhat.com/browse/JBTM-3122?page=com.atlassian.jira.plugin... ]
Mayank Kunwar updated JBTM-3122:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> jbosstm/quickstarts tests can't be run with jdk9+
> -------------------------------------------------
>
> Key: JBTM-3122
> URL: https://issues.redhat.com/browse/JBTM-3122
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Build System
> Affects Versions: 5.9.3.Final
> Reporter: Ondrej Chaloupka
> Assignee: Mayank Kunwar
> Priority: Major
>
> Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more).
> The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}.
> See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188
> {code}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
> --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED
> --add-modules=java.se
> {code}
> The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts.
> Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (JBTM-3132) Common parent maven module for Narayana quickstarts
by Mayank Kunwar (Jira)
[ https://issues.redhat.com/browse/JBTM-3132?page=com.atlassian.jira.plugin... ]
Mayank Kunwar commented on JBTM-3132:
-------------------------------------
The intention of pull/283 is to support JBTM-3122, so, the changes required for quickstart tests to run on JDK9+ versions are done as part of this pull request.
So every module that are required to run their tests over JDK9+ versions, only for them, I have included the parent in their pom.xml file, so that they could use same properties defined in parent pom.xml, when ran on JDK9+ versions.
Some of the modules in quickstart were not compiling when I tried adding parent to their pom.xml file, due to some incompatibility/conflicts specific to particular module with parent.
> Common parent maven module for Narayana quickstarts
> ---------------------------------------------------
>
> Key: JBTM-3132
> URL: https://issues.redhat.com/browse/JBTM-3132
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Testing
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Mayank Kunwar
> Priority: Major
>
> It would be beneficial to create a common quickstart maven module.
> My intention is to have a one place where we can define:
> * common profiles could be defined (one of such profile is Arquillian JDK9+ which defines JVM arguments needed for smooth run of tests, see https://issues.jboss.org/projects/JBTM/issues/JBTM-3122)
> * common properties like arquillian version. This has benefit that quickstarts will run faster on CI as there won't be multiple versions to be downloaded.
> * common repositories like jboss one
> * unified checkstyle definition for all the quickstarts would be coded in one way which makes them easier to read
> The quickstarts were designed to be independent on each other. The task is not to unified them. The proposal is about creating a place where a common stuff can be placed to. Otherwise the same configuration needs to be copied to multiple places. Which is hard to maintain
> Other projects, e.g. WildFly, use the same approach of common parent, see https://github.com/wildfly/quickstart/blob/master/app-client/pom.xml
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (JBTM-3309) Investigate using MicroProfile JSON Web Token to secure interaction with an LRA coordinator
by Michael Musgrove (Jira)
[ https://issues.redhat.com/browse/JBTM-3309?page=com.atlassian.jira.plugin... ]
Michael Musgrove updated JBTM-3309:
-----------------------------------
Priority: Critical (was: Major)
> Investigate using MicroProfile JSON Web Token to secure interaction with an LRA coordinator
> -------------------------------------------------------------------------------------------
>
> Key: JBTM-3309
> URL: https://issues.redhat.com/browse/JBTM-3309
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: LRA
> Affects Versions: 5.10.4.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Critical
> Fix For: 5.next
>
>
> The Narayana implementation of the MicroProfile LRA specification uses a JAX-RS filter to communicate with a remote coordinator. The interaction is currently insecure. This issue is to investigate the best way of securing this channel. Since the JAX-RS filter is applied to the MicroProfile service we should initially investigate the MicroProfile security solution (MicroProfile JSON Web Token).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (JBTM-3309) Investigate using MicroProfile JSON Web Token to secure interaction with an LRA coordinator
by Michael Musgrove (Jira)
Michael Musgrove created JBTM-3309:
--------------------------------------
Summary: Investigate using MicroProfile JSON Web Token to secure interaction with an LRA coordinator
Key: JBTM-3309
URL: https://issues.redhat.com/browse/JBTM-3309
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: LRA
Affects Versions: 5.10.4.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.next
The Narayana implementation of the MicroProfile LRA specification uses a JAX-RS filter to communicate with a remote coordinator. The interaction is currently insecure. This issue is to investigate the best way of securing this channel. Since the JAX-RS filter is applied to the MicroProfile service we should initially investigate the MicroProfile security solution (MicroProfile JSON Web Token).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (JBTM-3304) Performance comparison with Atomikos may loop forever
by Thomas Jenkinson (Jira)
[ https://issues.redhat.com/browse/JBTM-3304?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on JBTM-3304:
----------------------------------------
I think Atomikos does not loop forever, it reports an exception and the benchmark completes (for Atomikos). That said I think JOTM hangs the output of which I don't think is repeated continually, I think it does reach a state where it does not repeatedly log the same message but it does hang.
{code}
om.atomikos.icatch.jta.ExtendedSystemException: Unexpected error during enlist
at com.atomikos.icatch.jta.TransactionImp.enlistResource(TransactionImp.java:330)
at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:50)
at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:129)
at io.narayana.perf.product.ProductComparison.setup(ProductComparison.java:71)
at io.narayana.perf.product.generated.AtomikosComparison_test_jmhTest._jmh_tryInit_f_atomikoscomparison0_G(AtomikosComparison_test_jmhTest.java:438)
at io.narayana.perf.product.generated.AtomikosComparison_test_jmhTest.test_Throughput(AtomikosComparison_test_jmhTest.java:71)
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.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:453)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:437)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
com.atomikos.datasource.ResourceException: Failed to get branch
at com.atomikos.datasource.xa.SiblingMapper.findOrCreateBranchWithResourceException(SiblingMapper.java:95)
at com.atomikos.datasource.xa.SiblingMapper.findOrCreateBranchForTransaction(SiblingMapper.java:85)
at com.atomikos.datasource.xa.XATransactionalResource.getResourceTransaction(XATransactionalResource.java:367)
at com.atomikos.icatch.jta.TransactionImp.enlistResource(TransactionImp.java:307)
at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:50)
at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:129)
at io.narayana.perf.product.ProductComparison.setup(ProductComparison.java:71)
at io.narayana.perf.product.generated.AtomikosComparison_test_jmhTest._jmh_tryInit_f_atomikoscomparison0_G(AtomikosComparison_test_jmhTest.java:438)
at io.narayana.perf.product.generated.AtomikosComparison_test_jmhTest.test_Throughput(AtomikosComparison_test_jmhTest.java:71)
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.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:453)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:437)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Not yet initialized
at com.atomikos.datasource.xa.XATransactionalResource.createXid(XATransactionalResource.java:637)
at com.atomikos.datasource.xa.XAResourceTransaction.<init>(XAResourceTransaction.java:191)
at com.atomikos.datasource.xa.SiblingMapper.createNewBranch(SiblingMapper.java:114)
at com.atomikos.datasource.xa.SiblingMapper.findOrCreateBranch(SiblingMapper.java:106)
at com.atomikos.datasource.xa.SiblingMapper.findOrCreateBranchWithResourceException(SiblingMapper.java:93)
... 20 more
<failure>
org.openjdk.jmh.runner.BenchmarkException: Benchmark error
at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:134)
at io.narayana.perf.product.ProductComparison.setup(ProductComparison.java:71)
at io.narayana.perf.product.generated.AtomikosComparison_test_jmhTest._jmh_tryInit_f_atomikoscomparison0_G(AtomikosComparison_test_jmhTest.java:438)
at io.narayana.perf.product.generated.AtomikosComparison_test_jmhTest.test_Throughput(AtomikosComparison_test_jmhTest.java:71)
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.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:453)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:437)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: com.atomikos.icatch.jta.ExtendedSystemException: Unexpected error during enlist
at com.atomikos.icatch.jta.TransactionImp.enlistResource(TransactionImp.java:330)
at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:50)
at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:129)
... 15 more
{code}
> Performance comparison with Atomikos may loop forever
> -----------------------------------------------------
>
> Key: JBTM-3304
> URL: https://issues.redhat.com/browse/JBTM-3304
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Reporter: Michael Musgrove
> Assignee: Mayank Kunwar
> Priority: Major
>
> We have occasionally (though not common) seen our performance comparison (with other open source TMs) job loop forever when Atomikos fails to enlist a resource (for example job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-performance/4/).
> The correct behaviour should be to catch the error and abort the JMH run for that particular comparison.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (JBTM-3308) TckTests#closeLRA passes but the LRA is still active
by Martin Stefanko (Jira)
Martin Stefanko created JBTM-3308:
-------------------------------------
Summary: TckTests#closeLRA passes but the LRA is still active
Key: JBTM-3308
URL: https://issues.redhat.com/browse/JBTM-3308
Project: JBoss Transaction Manager
Issue Type: Bug
Components: LRA
Affects Versions: 5.10.4.Final
Reporter: Martin Stefanko
Assignee: Martin Stefanko
It seems that the LRA is correctly closed but the /lra-coordinator still reports it in Active status.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[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 updated JBTM-3302:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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.next
>
>
> 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)
5 years, 6 months