[jboss-jira] [JBoss JIRA] (AS7-5858) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
Bob Bennett (JIRA)
jira-events at lists.jboss.org
Mon Nov 5 09:45:19 EST 2012
[ https://issues.jboss.org/browse/AS7-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731802#comment-12731802 ]
Bob Bennett commented on AS7-5858:
----------------------------------
I passed the information from this issue along to IBM Java support, and I got this response:
Thanks for the update. I took a look at the JBOSS bug and their code
change. The XNIO code is their own I/O layer, so I'm unclear whether
they intend for the code-change to be an official fix, or if they
consider the IBM JVM defective in some way?
We have had two APARs in the SelectionKey NIO area, but they are both
fairly platform specific and shouldn't have resulted in this kind of
problem: IV27827 and IV30861.
The API for the "interestOps" method involved here does state that it
may block, and the documentation warns that concurrent thread usage of SelectionKey may wait for an operation to complete prior to updating the
data. See more details here:
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectionKey.
html
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectionKey.
html#interestOps(int)
>From the looks of the JBOSS code change, this area of their code
expected the interestOps method to return immediately after being
issued from an alternate thread. Their change appears to instruct the
owning thread to run the interestOps method instead... taking advantage
of the fact that it already holds ownership.
This, to me, seems like an appropriate final fix to resolve the deadlock
situation. Since the Java API specification grants the ability to our
code to take this Lock, I'm not sure I can qualify the IBM JVM behavior as defective. Could you confirm with JBOSS that they intend their fix to
be the resolution to this problem?
I can discuss the design of this code with development to see if the
lock being used can be avoided as a feature request for a future
release.
Regards,
--Mike Young
Java Defect Support
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: AS7-5858
> URL: https://issues.jboss.org/browse/AS7-5858
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.1.1.Final
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list