[jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
Stefan Stefan (JIRA)
issues at jboss.org
Tue Nov 25 05:33:40 EST 2014
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022637#comment-13022637 ]
Stefan Stefan commented on WFLY-825:
------------------------------------
Are there any news on this topic?
I've a similar problem with Wildfly 8.0.0.Final on IBM Power i with JDK 7 and JAX-RS Webservices that block on following Stacktrace:
{noformat}
3XMTHREADINFO "default task-1" J9VMThread:0x000000018D4C7E00, j9thread_t:0x0000000187F1C890, java/lang/Thread:0x0700000070D206D0, state:B, prio=5
3XMJAVALTHREAD (java/lang/Thread getId:0xA5, isDaemon:false)
3XMTHREADINFO1 (native thread ID:0x3DF015, native priority:0x5, native policy:UNKNOWN)
3XMTHREADBLOCK Blocked on: java/util/Collections$UnmodifiableSet at 0x07000000016445B0 Owned by: "default I/O-1" (J9VMThread:0x0000000186EB7F00, java/lang/Thread:0x070000000166BC98)
3XMHEAPALLOC Heap bytes allocated since last GC cycle=1426832 (0x15C590)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:133)
4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:95)
4XESTACKTRACE at org/xnio/nio/WorkerThread.setOps(WorkerThread.java:738)
4XESTACKTRACE at org/xnio/nio/NioHandle.resume(NioHandle.java:42)
4XESTACKTRACE at org/xnio/nio/NioSocketConduit.resumeReads(NioSocketConduit.java:324)
4XESTACKTRACE at org/xnio/conduits/ConduitStreamSourceChannel.resumeReads(ConduitStreamSourceChannel.java:135)
4XESTACKTRACE at io/undertow/server/protocol/http/HttpReadListener.exchangeComplete(HttpReadListener.java:219)
4XESTACKTRACE at io/undertow/server/protocol/http/HttpServerConnection.exchangeComplete(HttpServerConnection.java:218)
4XESTACKTRACE at io/undertow/server/HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1090)
4XESTACKTRACE at io/undertow/server/HttpServerExchange.terminateResponse(HttpServerExchange.java:1310)
4XESTACKTRACE at io/undertow/server/Connectors.terminateResponse(Connectors.java:69)
4XESTACKTRACE at io/undertow/server/protocol/http/ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
4XESTACKTRACE at io/undertow/conduits/AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:249)
4XESTACKTRACE at io/undertow/conduits/AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:183)
4XESTACKTRACE at org/xnio/conduits/ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
4XESTACKTRACE at io/undertow/channels/DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
4XESTACKTRACE at org/xnio/channels/Channels.flushBlocking(Channels.java:63)
4XESTACKTRACE at io/undertow/servlet/spec/ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623)
4XESTACKTRACE at io/undertow/servlet/spec/HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
4XESTACKTRACE at io/undertow/servlet/spec/HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.access$000(ServletInitialHandler.java:73)
4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
4XESTACKTRACE at io/undertow/server/Connectors.executeRootHandler(Connectors.java:168)
4XESTACKTRACE at io/undertow/server/HttpServerExchange$1.run(HttpServerExchange.java:687)
4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
4XESTACKTRACE at java/lang/Thread.run(Thread.java:780)
{noformat}
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
More information about the jboss-jira
mailing list