[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension
by Florian Sailer (Jira)
Florian Sailer created WFLY-12461:
-------------------------------------
Summary: Can't use smallrye-health without weld extension
Key: WFLY-12461
URL: https://issues.jboss.org/browse/WFLY-12461
Project: WildFly
Issue Type: Bug
Components: MP Health
Affects Versions: 17.0.1.Final
Reporter: Florian Sailer
Assignee: Jeff Mesnil
Since this commit in the smallrye implementation it was possible to use smallrye without CDI.
https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29...
I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld.
I am getting the following exception while starting:
14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available:
org.wildfly.weld; There are no known registration points which can provide this capability.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
9 months, 4 weeks
[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-12613?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-12613:
--------------------------------------------
The current release of arquillian-extension-byteman in Wildly, namely 1.0.0, has an issue with running against JVMs where JDK > 8, due to an issue with jigsaw which was introduced in JDK 9. This issue was fixed in arquillian-extension-byteman version 1.1.0. So, I shall upgrade the version of arquillian-extension-byteman at the same time as fixing this issue.
In Wildfly-18.0.0.FinaI-SNAPSHOT, did the following:
- updated the version of arquillian-byteman-extension from 1.0.0 (the buggy version) to 1.1.0 (the fixed version)
- removed any constraint preventing the test LastNodeToLeaveRemoteEJBTestCase from running
The results were:
- fails on IBM J9 VM (the current issue) (java.version="1.8.0", java.vendor="IBM Corporation")
- passes on OpenJDK8 + OpenJ9 JVM (java.version="1.8.0.222", java.vendor="Eclipse OpenJ9")
- passes on OpenJDK11 + OpenJ9 JVM (java.version="11.0.4.0", java.vendor="Eclipse OpenJ9")
So, it seems that we need only exclude this test from test executions for which:
* java.version starts with 1.8 and
* java.vendor equals "IBM Corporation"
> Exclude IBM J9 JVM from Byteman-based test cases
> ------------------------------------------------
>
> Key: WFLY-12613
> URL: https://issues.jboss.org/browse/WFLY-12613
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 18.0.0.Final
> Reporter: Richard Achmatowicz
> Priority: Major
> Fix For: 18.0.0.Final
>
>
> The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case.
> There is a problem with running Byteman-based test cases against the IBM J9 Java runtime:
> {noformat}
> [ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR!
> java.lang.RuntimeException: Could not install byteman agent
> at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
> at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
> at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102
> at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66)
> at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91)
> ... 28 more
> {noformat}
>
> {noformat}
> [nrla@localhost wildfly-git-repo]$ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR2_20151019_2144_B272764
> JIT - tr.r14.java_20151006_102517.04
> GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
> J9CL - 20151019_272764)
> JCL - 20151022_01 based on Oracle jdk8u65-b17
> {noformat}
> Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-12613?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz updated WFLY-12613:
---------------------------------------
Description:
The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case.
There is a problem with running Byteman-based test cases against the IBM J9 Java runtime:
{noformat}
[ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR!
java.lang.RuntimeException: Could not install byteman agent
at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102
at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66)
at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91)
... 28 more
{noformat}
{noformat}
[nrla@localhost wildfly-git-repo]$ java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR2_20151019_2144_B272764
JIT - tr.r14.java_20151006_102517.04
GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
J9CL - 20151019_272764)
JCL - 20151022_01 based on Oracle jdk8u65-b17
{noformat}
Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM.
was:
The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case.
There is a problem with running Byteman-based test cases with the IBM J9 Java runtime:
{noformat}
[ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR!
java.lang.RuntimeException: Could not install byteman agent
at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102
at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66)
at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91)
... 28 more
{noformat}
{noformat}
[nrla@localhost wildfly-git-repo]$ java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR2_20151019_2144_B272764
JIT - tr.r14.java_20151006_102517.04
GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
J9CL - 20151019_272764)
JCL - 20151022_01 based on Oracle jdk8u65-b17
{noformat}
Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM.
> Exclude IBM J9 JVM from Byteman-based test cases
> ------------------------------------------------
>
> Key: WFLY-12613
> URL: https://issues.jboss.org/browse/WFLY-12613
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 18.0.0.Final
> Reporter: Richard Achmatowicz
> Priority: Major
> Fix For: 18.0.0.Final
>
>
> The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case.
> There is a problem with running Byteman-based test cases against the IBM J9 Java runtime:
> {noformat}
> [ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR!
> java.lang.RuntimeException: Could not install byteman agent
> at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
> at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
> at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102
> at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66)
> at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91)
> ... 28 more
> {noformat}
>
> {noformat}
> [nrla@localhost wildfly-git-repo]$ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR2_20151019_2144_B272764
> JIT - tr.r14.java_20151006_102517.04
> GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
> J9CL - 20151019_272764)
> JCL - 20151022_01 based on Oracle jdk8u65-b17
> {noformat}
> Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFLY-12613:
------------------------------------------
Summary: Exclude IBM J9 JVM from Byteman-based test cases
Key: WFLY-12613
URL: https://issues.jboss.org/browse/WFLY-12613
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 18.0.0.Final
Reporter: Richard Achmatowicz
Fix For: 18.0.0.Final
The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case.
There is a problem with running Byteman-based test cases with the IBM J9 Java runtime:
{noformat}
[ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR!
java.lang.RuntimeException: Could not install byteman agent
at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102
at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66)
at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91)
... 28 more
{noformat}
{noformat}
[nrla@localhost wildfly-git-repo]$ java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR2_20151019_2144_B272764
JIT - tr.r14.java_20151006_102517.04
GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS
J9CL - 20151019_272764)
JCL - 20151022_01 based on Oracle jdk8u65-b17
{noformat}
Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-12612) Add Galleon layers testing to testsuite/integration/elytron
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12612:
---------------------------------------
Summary: Add Galleon layers testing to testsuite/integration/elytron
Key: WFLY-12612
URL: https://issues.jboss.org/browse/WFLY-12612
Project: WildFly
Issue Type: Task
Components: Build System, Security, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Follow up on the WFLY-12394 work by adding a profile triggered by -Dts.layers to testsuite/integration/elytron. Provision a slimmed server using the test-feature-pack cloud-server layer and execute the portions of the testsuite that are compatible with such a server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-12611) Add Galleon layers testing to testsuite/integration/clustering
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12611:
---------------------------------------
Summary: Add Galleon layers testing to testsuite/integration/clustering
Key: WFLY-12611
URL: https://issues.jboss.org/browse/WFLY-12611
Project: WildFly
Issue Type: Task
Components: Build System, Clustering, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Follow up on the WFLY-12394 work by adding a profile triggered by -Dts.layers to testsuite/integration/clustering. Provision a slimmed server using the test-feature-pack cloud-server + web-clustering layers and execute the portions of the testsuite that are compatible with such a server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays
by Brian Dellascio (Jira)
[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ]
Brian Dellascio reopened DROOLS-4449:
-------------------------------------
After meeting with [~uxdlc], [~danielezonca], [~tirelli] last week, need to make some more adjustments to the design to account for the following:
* Row matched and used
* Row matched and not used
* The parent cell needs a summary of the result for all cases (pass, fail) - another icon? Some other affordance?
Also decided:
* Row did not match - no treatment
Will return to this work once the higher priority 7.6 work is completed.
> Visual design enhancements: Scenario/DMN error overlays
> -------------------------------------------------------
>
> Key: DROOLS-4449
> URL: https://issues.jboss.org/browse/DROOLS-4449
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Brian Dellascio
> Priority: Major
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
> Attachments: ban-solid.svg, check-circle-regular.svg, check-circle-solid.svg, exclamation-circle-regular.svg, exclamation-circle-solid.svg
>
>
> Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context.
> Verification conditions:
> - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN)
> - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-12601) Eliminate StabilityMonitor usages in clustering subsystem
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12601?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-12601:
-------------------------------------
[~ropalka] OK - I've updated the PR to address the issues with ServiceSupplier. Can you have a look?
> Eliminate StabilityMonitor usages in clustering subsystem
> ---------------------------------------------------------
>
> Key: WFLY-12601
> URL: https://issues.jboss.org/browse/WFLY-12601
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Richard Opalka
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 19.0.0.Beta1
>
> Attachments: ServiceSupplier.png
>
>
> Clustering needs to eliminate usages of StabilityMonitor because SM is not reliable.
> It is possible that SM will prematurely inform about achieved stability even if it is not true.
> The reason is SM is not propagated up the dependencies chain and thus it may report
> about achieved stability even in case dependencies chain didn't finish its processing yet
> and 'real' stability wasn't achieved yet.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFWIP-206) scale down isn't successful when there are in-doubt transaction on pod
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFWIP-206?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka commented on WFWIP-206:
----------------------------------------
current state with {{quay.io/ochaloup/wildfly-operator:20190930}}
{{-Dtest=EjbTxnRemotingScaleDownTest#}}
* {{testTxStatelessServerSecondCommitThrowRmFail}} - transaction are stuck in object store: transaction list: map[0:ffffac11000a:-77005aaf:5d92202c:13:map[age-in-seconds:109 id:0:ffffac11000a:-77005aaf:5d92202c:13 jmx-name:<nil> participants:map[java:/MockXAResource:map[eis-product-name:MockXAResource Test eis-product-version:0.1.Mock jmx-name:<nil> jndi-name:java:/MockXAResource status:PREPARED type:/StateManager/AbstractRecord/XAResourceRecord]] type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA]] at `tx-server-0`
* {{testTxStatelessClientSecondCommitThrowRmFail}} - PASSes
{{testTxStatelessServerSecondPrepareJvmHalt}} - server is scaled down and rollback is expected to be called before scaledown (operator issue?) -> FIXED with the latest commit at operator and PASSes
* {{testTxStatelessClientSecondPrepareJvmHalt}} - /opt/eap/standalone/data/ejb-xa-recovery is never cleaned (wftc record left forever) at `tx-client-0`
Failure of {{testTxStatelessClientSecondPrepareJvmHalt}} and {{testTxStatelessServerSecondCommitThrowRmFail}} can be caused by Elytron non-configuration of the recovery processing. Maybe S2I issue...
> scale down isn't successful when there are in-doubt transaction on pod
> ----------------------------------------------------------------------
>
> Key: WFWIP-206
> URL: https://issues.jboss.org/browse/WFWIP-206
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: operator, built from [1984d98154f11a7473be065e4ae7f54b1812c9b0|https://github.com/wildfly/wildf...] :
> {noformat}
> docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:latest
> {noformat}
> EAP image:
> {noformat}
> docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909...
> {noformat}
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Blocker
> Labels: operator
>
> While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful
> Scenario:
> *ejb client* (app tx-client, pod tx-client-0):
> * EJB business method
> ** lookup remote EJB
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ** call remote EJB
> *ejb server* (app tx-server, pod tx-server-0):
> * EJB business method
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
> Then the test calls scale down (size from 1 to 0) on tx-server pod. But scale down never completes.
> Log from operator:
> {noformat}
> {"level":"info","ts":1568905676.6303623,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905676.7313502,"logger":"controller_wildflyserver","msg":"Enabling recovery listener for processing scaledown at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905679.4325309,"logger":"controller_wildflyserver","msg":"Query to find the transaction recovery port to force scan at pod tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905686.7914035,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"info","ts":1568905702.0583296,"logger":"controller_wildflyserver","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","Message":"Recovery scan to be invoked as the transaction log storage is not empty for pod scaling down pod tx-server-0, transaction list: map[0:ffffac11000a:991c183:5d8399a1:13:map[age-in-seconds:23 id:0:ffffac11000a:991c183:5d8399a1:13 jmx-name:<nil> participants:map[java:/MockXAResource:map[eis-product-name:MockXAResource Test eis-product-version:0.1.Mock jmx-name:<nil> jndi-name:java:/MockXAResource status:PREPARED type:/StateManager/AbstractRecord/XAResourceRecord]] type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA]]"}
> {"level":"info","ts":1568905711.1034026,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.103548,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.109706,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.2608829,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Error to get response for command SCAN sending to 172.17.0.10:4712, error: EOF]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.2609518,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2609615,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795022,"logger":"controller_wildflyserver","msg":"Updating StatefulSet to be up to date with the WildFlyServer Spec","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795491,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.2796504,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.2937052,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.294249,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.294342,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.294417,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"error","ts":1568905711.311673,"logger":"controller_wildflyserver","msg":"Failed to Update StatefulSet.","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1568905711.311745,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"msimka-namespace/tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3137681,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905712.3139439,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905712.3253288,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905712.3255754,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3256311,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905712.3256419,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months