[JBoss JIRA] (WFLY-12752) RankedAffinityTestCase fails on OpenJ9
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12752:
-----------------------------------
Summary: RankedAffinityTestCase fails on OpenJ9
Key: WFLY-12752
URL: https://issues.jboss.org/browse/WFLY-12752
Project: WildFly
Issue Type: Bug
Components: Clustering, Test Suite
Affects Versions: 18.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
{noformat}
java.lang.NoSuchMethodError: org/bouncycastle/util/Arrays.append([Ljava/lang/String;Ljava/lang/String;)[Ljava/lang/String; (loaded from file:/store/repository/org/apache/directory/server/apacheds-all/2.0.0-M24/apacheds-all-2.0.0-M24.jar by jdk.internal.loader.ClassLoaders$AppClassLoader@b33b58fe) called from class org.jboss.as.test.clustering.cluster.affinity.RankedAffinityTestCase (loaded from file:/store/work/tc-work/aa09375132417a7/testsuite/integration/clustering/target/test-classes/ by jdk.internal.loader.ClassLoaders$AppClassLoader@b33b58fe).
at org.jboss.as.test.clustering.cluster.affinity.RankedAffinityTestCase.<init>(RankedAffinityTestCase.java:85)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)
at org.jboss.arquillian.junit.Arquillian.access$300(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$6.runReflectiveCall(Arquillian.java:240)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.jboss.arquillian.junit.Arquillian.methodBlock(Arquillian.java:242)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
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)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time
by Dan Berindei (Jira)
Dan Berindei created JGRP-2395:
----------------------------------
Summary: LOCAL_PING fails when 2 nodes start at the same time
Key: JGRP-2395
URL: https://issues.jboss.org/browse/JGRP-2395
Project: JGroups
Issue Type: Bug
Affects Versions: 4.1.6
Reporter: Dan Berindei
Assignee: Bela Ban
We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}.
{noformat}
01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done]
01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done]
01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done]
01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator
01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done]
01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
...
01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done]
01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550]
01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator
01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton
01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550]
01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
{noformat}
The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times.
In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator:
{noformat}
01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member
01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done]
01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done]
01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386]
01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator
01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165]
01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386]
{noformat}
This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-3739) [IBM JDK] Unable to start server with FIPS Bouncy Castle
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-3739?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3739:
----------------------------------
Labels: OpenJ9 (was: )
> [IBM JDK] Unable to start server with FIPS Bouncy Castle
> --------------------------------------------------------
>
> Key: WFCORE-3739
> URL: https://issues.jboss.org/browse/WFCORE-3739
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Alpha2
> Environment: java -version
> java version "1.8.0_161"
> Java(TM) SE Runtime Environment (build 8.0.5.10 - pxa6480sr5fp10-20180214_01(SR5 FP10))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20180208_378436 (JIT enabled, AOT enabled)
> OpenJ9 - 39bb844
> OMR - c04ccb2
> IBM - 2321a81)
> JCL - 20180209_01 based on Oracle jdk8u161-b12
> Reporter: Martin Choma
> Priority: Major
> Labels: OpenJ9
>
> {code}
> 18:09:45,494 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.as: org.jboss.msc.service.StartException in service jboss.as: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1706)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:811)
> Caused by: java.lang.IllegalStateException: WFLYDR0005: Cannot obtain SHA-1 MessageDigest
> at org.jboss.as.repository.ContentRepositoryImpl.<init>(ContentRepositoryImpl.java:92)
> at org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:185)
> at org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:145)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> ... 6 more
> Caused by: java.security.NoSuchAlgorithmException: SHA-1 MessageDigest not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:171)
> at java.security.Security.getImpl(Security.java:706)
> at java.security.MessageDigest.getInstance(MessageDigest.java:178)
> at org.jboss.as.repository.ContentRepositoryImpl.<init>(ContentRepositoryImpl.java:90)
> ... 10 more
> {code}
> SHA-1 is hardcoded in server, which apparently is not available in FIPS BC.
> {code:java|title=ContentRepositoryImpl.java}
> protected ContentRepositoryImpl(final File repoRoot, final File tmpRoot, long obsolescenceTimeout, long lockTimeout) {
> Assert.checkNotNullParam("repoRoot", repoRoot);
> Assert.checkNotNullParam("tmpRoot", tmpRoot);
> checkDirectory(repoRoot);
> this.repoRoot = repoRoot;
> checkDirectory(tmpRoot);
> this.tmpRoot = tmpRoot;
> this.obsolescenceTimeout = obsolescenceTimeout;
> this.lockTimeout = lockTimeout;
> try {
> this.messageDigest = MessageDigest.getInstance("SHA-1");
> } catch (NoSuchAlgorithmException e) {
> throw DeploymentRepositoryLogger.ROOT_LOGGER.cannotObtainSha1(e, MessageDigest.class.getSimpleName());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4143) Embed CLI failures on IBM jdk - checkLogging
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4143?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-4143:
----------------------------------
Labels: OpenJ9 (was: )
> Embed CLI failures on IBM jdk - checkLogging
> --------------------------------------------
>
> Key: WFCORE-4143
> URL: https://issues.jboss.org/browse/WFCORE-4143
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Environment: IBM JDK
> {noformat}
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 8.0.5.20 - pxa6480sr5fp20-20180802_01(SR5 FP20))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20180731_393394 (JIT enabled, AOT enabled)
> OpenJ9 - bd23af8
> OMR - ca1411c
> IBM - 98805ca)
> JCL - 20180719_01 based on Oracle jdk8u181-b12
> {noformat}
> Reporter: Petr Kremensky
> Assignee: James Perkins
> Priority: Major
> Labels: OpenJ9
>
> {{testLogging}} for Cli tests in Wildfly-core testsuite fails on IBM JDK.
> *reproduce*
> cd wildfly-core/testsuite
> mvn clean test -fae -Dts.manualmode -pl manualmode,standalone -Dtest=CLIEmbedHostControllerTestCase,CLIEmbedServerTestCase,SilentModeTestCase
> ...
> [ERROR] Failures:
> [ERROR] SilentModeTestCase.testLogging:99->checkIfEmpty:152
> [INFO]
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0
> ...
> [ERROR] Failures:
> [ERROR] CLIEmbedHostControllerTestCase.testHelp:321->checkLogging:744
> [ERROR] CLIEmbedHostControllerTestCase.testStdOutDefault:160->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
> [ERROR] CLIEmbedHostControllerTestCase.testStdOutDiscard:166->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
> [ERROR] CLIEmbedHostControllerTestCase.testStdOutEcho:172->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
> [ERROR] CLIEmbedServerTestCase.testHelp:543->checkLogging:764
> [ERROR] CLIEmbedServerTestCase.testStdOutDefault:196->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
> [ERROR] CLIEmbedServerTestCase.testStdOutDiscard:202->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
> [ERROR] CLIEmbedServerTestCase.testStdOutEcho:208->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
> [INFO]
> [ERROR] Tests run: 51, Failures: 8, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFLY-8595) Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-8595?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-8595.
-------------------------------
Resolution: Explained
I'm closing this as explained. The log manager must be on the boot class path, along with it's dependencies, and the {{java.util.logging.manager}} system property needs to be set in the JVM options.
The {{JBOSS_MODULES_SYSTEM_PKGS}} environment variable also needs to be set. Here are some snippets on how this could be done with WildFly 18+
{code:title=standalone.conf}
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager,org.wildfly.common,$JBOSS_MODULES_SYSTEM_PKGS"
...
LOGMANAGER_JAR=$(find $JBOSS_HOME/modules -name "jboss-logmanager*.jar" -type f | xargs readlink -m)
WILDFLY_COMMON_JAR=$(find $JBOSS_HOME/modules -name "wildfly-common*.jar" -type f | xargs readlink -m)
JSON_API_JAR=$(find $JBOSS_HOME/modules -name "jakarta.json-api*.jar" -type f | xargs readlink -m)
JSON_IMPL_JAR=$(find $JBOSS_HOME/modules -name "jakarta.json-1*.jar" -type f | xargs readlink -m)
BOOT_CP="$LOGMANAGER_JAR:$WILDFLY_COMMON_JAR:$JSON_API_JAR:$JSON_IMPL_JAR"
JAVA_OPTS="-Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/a:$BOOT_CP -Xhealthcenter $JAVA_OPTS"
{code}
> Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8595
> URL: https://issues.jboss.org/browse/WFLY-8595
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Affects Versions: 10.1.0.Final
> Environment: * Wildfly 10.1
> * IBM JDK 8
> * YAJSW 11
> Reporter: will milspec
> Assignee: James Perkins
> Priority: Major
>
> *Upshot*
> Wildfly 10.1 fails to run when called from YAJSW (Yet Another Service Wrapper) on the IBM JDK.
> It fails because YAJSW instantiates/calls MemoryMXBean prior to running the wildfly classes.
> IBM's implementation of MemoryMXBean instantiates the Logging manager, i.e. class identified by -Djava.util.logging.manager.
> A "class/classloader" conflict exists for the logging manager. Because IBM JDK's MemoryMXBean "got to the log manager" first, wildfly presuppositions are undermined, i.e. the "system classloader" loaded the log manager, not the "jboss module classloader". A 'class identify check' (see below) fails.
> *More Details*
> This test returns false for Oracle JDK, true for IBM when run under yajsw. i.e. Under OracleJDK, LogManager.getLogManager() has a different classloader (the jboss module classoader ) than does the LogManager.class (system classloader)
> jboss-modules.git/src/main/java/org/jboss/modules/Main.java
> {{ final String logManagerName = getServiceName(bootClassLoader, "java.util.logging.LogMa
> nager");
> if (logManagerName != null) {
> System.setProperty("java.util.logging.manager", logManagerName);
> * if (LogManager.getLogManager().getClass() == LogManager.class) {
> * System.err.println("WARNING: Failed to load the specified log manager class " + logManagerName);
> } else {
> Module.setModuleLogger(new JDKModuleLogger());
> }
> }
> }}
> *Workaround Gets Farther but Undermines Presuppositions of App Server*
> If I add this jar to the Xbootclasspath/p, the "ibm system classes" loads org.jboss.logmanager.LogManager, but a downstream check in the jboss code throws an exception because the wrong classloader loaded org.jboss.logmanager.LogManager.
> *Steps to Reproduce*
> -Download IBM JDK
> -Download yajsw. Run its "genconfig" tool to generate a configration file
> -Start wildfly
> *Resource Xref*
> When I first came across this issue, I had trouble discerning "where the problem lay", i.e. in what source code. I posted on the ibm developer works, yajsw and wildfly forums.
> https://sourceforge.net/p/yajsw/discussion/810311/thread/e730451b/
> ibm developer works forum:
> https://www.ibm.com/developerworks/community/forums/html/topic?id=8e9e4ae...
> jboss developer forum:
> https://developer.jboss.org/thread/272840
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFLY-9169) Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-9169?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-9169.
-------------------------------
Resolution: Out of Date
I'm closing this as out of date. If this is still an issue with WildFly 18 please feel free to reopen.
> Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE)
> --------------------------------------------------------------------------
>
> Key: WFLY-9169
> URL: https://issues.jboss.org/browse/WFLY-9169
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final
> AIX Version 7.2
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pap6480sr3fp22-20161213_02(SR3 FP22))
> IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20161209_329148 (JIT enabled, AOT enabled)
> J9VM - R28_20161209_1345_B329148
> JIT - tr.r14.java.green_20161207_128946
> GC - R28_20161209_1345_B329148_CMPRSS
> J9CL - 20161209_329148)
> JCL - 20161213_01 based on Oracle jdk8u111-b14
> Reporter: Blass MeGod
> Priority: Major
> Labels: deadlock, regression, remoting
>
> Deadlock on AbstractHandleableCloseable close() method (AIX - IBM JDK/JRE):
> {code}
> 3XMTHREADINFO "p0" J9VMThread:0x00000000304BD100, j9thread_t:0x0000010029E423D0, java/lang/Thread:0x0000000408F664F8, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x8C96, isDaemon:false)
> 3XMTHREADINFO1 (native thread ID:0x20401E7, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000101)
> 3XMCPUTIME CPU usage total: 0.379679000 secs, user: 0.354485000 secs, system: 0.025194000 secs, current category="Application"
> 3XMTHREADBLOCK Waiting on: java/lang/Object@0x000000040ECC59A0 Owned by: <unowned>
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/lang/Object.wait(Native Method)
> 4XESTACKTRACE at java/lang/Object.wait(Object.java:172(Compiled Code))
> 4XESTACKTRACE at org/jboss/remoting3/spi/AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190(Compiled Code))
> 5XESTACKTRACE (entered lock: java/lang/Object@0x000000040ECC59A0, entry count: 1)
> 4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache.release(EndpointCache.java:67(Compiled Code))
> 5XESTACKTRACE (entered lock: org/jboss/naming/remote/client/EndpointCache@0x00000004002F3830, entry count: 1)
> 4XESTACKTRACE at org/jboss/naming/remote/client/EndpointCache$EndpointWrapper.close(EndpointCache.java:183(Compiled Code))
> 4XESTACKTRACE at org/jboss/naming/remote/client/InitialContextFactory$1.close(InitialContextFactory.java:233(Compiled Code))
> 4XESTACKTRACE at org/jboss/naming/remote/client/RemoteContext.close(RemoteContext.java:290(Compiled Code))
> 4XESTACKTRACE at javax/naming/InitialContext.close(InitialContext.java:567(Compiled Code))
> ...
> {code}
> This might happen when using remoting client with XNIO version 3.3.4
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months