[JBoss JIRA] (WFWIP-187) Changes to PVC are not reflected in Operator
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-187?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFWIP-187:
------------------------------------
It is really ignored. I am trying on OpenShift with wildfly-operator. If I add `sizeLimit: 2Mi` directly to StatefulSet it is throw away on Save. This behaves the same if I add any unknow parameter e.g. `a: b`
I will create OpenShift issue for that to be explained.
> Changes to PVC are not reflected in Operator
> --------------------------------------------
>
> Key: WFWIP-187
> URL: https://issues.jboss.org/browse/WFWIP-187
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> Any chnages (adding, removing or updating) made to PVC after WildFlyServer CR was created are not reflected in underlying PVC kubernetes object.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12624) Return hostname instead of IP address when generating default client mapping
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-12624?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-12624:
--------------------------------------------
There are two parts to this problem: the data input to the algorithm, and the algorithm itself.
The algorithm assumes that different strings (e..g "127.0.0.1" and "localhost") represent different hosts.
However, this assumption is not being met because:
* data from Remoting connections is always in hostname form
* data from client mappings can be either in hostname form or IP address form
So, we have this problem.
Fixing the algorithm to work under the assumption that two distinct strings may represent the same host, is possible. However, doing DNS reverse lookups to convert between IP addresses and hostnames is unwanted. It may be possible to work around this, based on the way information is stored in the DNR.
> Return hostname instead of IP address when generating default client mapping
> -----------------------------------------------------------------------------
>
> Key: WFLY-12624
> URL: https://issues.jboss.org/browse/WFLY-12624
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Environment: An EJB client application interacting with a cluster of Wildfly server nodes
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster.
> For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port.
> Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example:
> {noformat}
> <socket-binding name="remoting" port="1099">
> <client-mapping source-network="135.121.1.29/16" destination-address="135.121.1.29" destination-port="1099"/>
> </socketbinding>
> {noformat}
> When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters.
> When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. The Discovery component uses "an algorithm" to take the information in the DNR (and other places) and convert that information to a corresponding set of ServiceURLs representing available targets. The Discovery component will then select one such ServiceURL and return this as the target for the invocation.
> Discovery obtains node information used in the algorithm from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port.
> The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. If a mix of hostnames and IP addresses for the same node is received, this results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFWIP-221?page=com.atlassian.jira.plugin.... ]
Jan Blizňák updated WFWIP-221:
------------------------------
Description:
This is somewhat curious issue.
When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and I can find java process in /proc/*/cmdline (image has no `ps` utility).
This happens only in Openshift environment and it is a regression to what was working with latest published CD image.
Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process.
{code:java}
# this works fine
docker run -it docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP... sh
sh-4.4$ /opt/eap/bin/openshift-launch.sh &
sh-4.4$ jps -l
{code}
was:
This is somewhat curious issue.
When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and can find java process in /proc/*/cmdline (image has no `ps` utility).
This happens only in Openshift environment and is a regression to what was working with latest published CD image.
Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process.
> jps can't see server process in Openshift
> -----------------------------------------
>
> Key: WFWIP-221
> URL: https://issues.jboss.org/browse/WFWIP-221
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
>
> This is somewhat curious issue.
> When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and I can find java process in /proc/*/cmdline (image has no `ps` utility).
> This happens only in Openshift environment and it is a regression to what was working with latest published CD image.
> Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process.
> {code:java}
> # this works fine
> docker run -it docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP... sh
> sh-4.4$ /opt/eap/bin/openshift-launch.sh &
> sh-4.4$ jps -l
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFWIP-221?page=com.atlassian.jira.plugin.... ]
Jan Blizňák updated WFWIP-221:
------------------------------
Steps to Reproduce:
Either in gui switch to Terminal tab and type `jps` or use remote shell
{code:java}
oc login
oc rsh <pod name> jps -l
{code}
> jps can't see server process in Openshift
> -----------------------------------------
>
> Key: WFWIP-221
> URL: https://issues.jboss.org/browse/WFWIP-221
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
>
> This is somewhat curious issue.
> When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and can find java process in /proc/*/cmdline (image has no `ps` utility).
> This happens only in Openshift environment and is a regression to what was working with latest published CD image.
> Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12624) Return hostname instead of IP address when generating default client mapping
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-12624?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz reassigned WFLY-12624:
------------------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> Return hostname instead of IP address when generating default client mapping
> -----------------------------------------------------------------------------
>
> Key: WFLY-12624
> URL: https://issues.jboss.org/browse/WFLY-12624
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Environment: An EJB client application interacting with a cluster of Wildfly server nodes
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster.
> For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port.
> Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example:
> {noformat}
> <socket-binding name="remoting" port="1099">
> <client-mapping source-network="135.121.1.29/16" destination-address="135.121.1.29" destination-port="1099"/>
> </socketbinding>
> {noformat}
> When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters.
> When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. The Discovery component uses "an algorithm" to take the information in the DNR (and other places) and convert that information to a corresponding set of ServiceURLs representing available targets. The Discovery component will then select one such ServiceURL and return this as the target for the invocation.
> Discovery obtains node information used in the algorithm from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port.
> The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. If a mix of hostnames and IP addresses for the same node is received, this results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12624) Return hostname instead of IP address when generating default client mapping
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-12624?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz updated WFLY-12624:
---------------------------------------
Description:
When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster.
For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port.
Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example:
{noformat}
<socket-binding name="remoting" port="1099">
<client-mapping source-network="135.121.1.29/16" destination-address="135.121.1.29" destination-port="1099"/>
</socketbinding>
{noformat}
When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters.
When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. The Discovery component uses "an algorithm" to take the information in the DNR (and other places) and convert that information to a corresponding set of ServiceURLs representing available targets. The Discovery component will then select one such ServiceURL and return this as the target for the invocation.
Discovery obtains node information used in the algorithm from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port.
The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. If a mix of hostnames and IP addresses for the same node is received, this results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures.
was:
When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster.
For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port.
Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example:
{noformat}
<socket-binding name="remoting" port="1099">
<client-mapping source-network="135.121.1.29/16" destination-address="135.121.1.29" destination-port="1099"/>
</socketbinding>
{noformat}
When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters.
When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. These service URLs use "an algorithm" to take the information in the DNR and convert that information to a corresponding set of ServiceURLs. The Discovery component will then select one such ServiceURL and return this as the target for the invocation.
The problem is that Discovery obtains its node information from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port.
The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. This results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures.
> Return hostname instead of IP address when generating default client mapping
> -----------------------------------------------------------------------------
>
> Key: WFLY-12624
> URL: https://issues.jboss.org/browse/WFLY-12624
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Environment: An EJB client application interacting with a cluster of Wildfly server nodes
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Priority: Major
>
> When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster.
> For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port.
> Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example:
> {noformat}
> <socket-binding name="remoting" port="1099">
> <client-mapping source-network="135.121.1.29/16" destination-address="135.121.1.29" destination-port="1099"/>
> </socketbinding>
> {noformat}
> When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters.
> When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. The Discovery component uses "an algorithm" to take the information in the DNR (and other places) and convert that information to a corresponding set of ServiceURLs representing available targets. The Discovery component will then select one such ServiceURL and return this as the target for the invocation.
> Discovery obtains node information used in the algorithm from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port.
> The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. If a mix of hostnames and IP addresses for the same node is received, this results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift
by Michal Jurc (Jira)
[ https://issues.jboss.org/browse/WFWIP-221?page=com.atlassian.jira.plugin.... ]
Michal Jurc updated WFWIP-221:
------------------------------
Priority: Critical (was: Major)
> jps can't see server process in Openshift
> -----------------------------------------
>
> Key: WFWIP-221
> URL: https://issues.jboss.org/browse/WFWIP-221
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
>
> This is somewhat curious issue.
> When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and can find java process in /proc/*/cmdline (image has no `ps` utility).
> This happens only in Openshift environment and is a regression to what was working with latest published CD image.
> Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift
by Jan Blizňák (Jira)
Jan Blizňák created WFWIP-221:
---------------------------------
Summary: jps can't see server process in Openshift
Key: WFWIP-221
URL: https://issues.jboss.org/browse/WFWIP-221
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Jan Blizňák
Assignee: Jean Francois Denise
This is somewhat curious issue.
When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and can find java process in /proc/*/cmdline (image has no `ps` utility).
This happens only in Openshift environment and is a regression to what was working with latest published CD image.
Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[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 reassigned WFLY-12613:
------------------------------------------
Assignee: Richard Achmatowicz
> 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
> Assignee: 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)
6 years