[jboss-jira] [JBoss JIRA] (AS7-5858) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/AS7-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730823#comment-12730823 ] 

David Lloyd commented on AS7-5858:
----------------------------------

I pushed up a slightly different solution that will accept a system property -Dxnio.xnio.old-locking so that only platforms with this kind of locking are impacted.  I've attached a JAR to test (be sure to set that system property).  If it works then I can push a release and I can talk to Jimmy about the disposition of the change with respect to releases and that sort of thing.
                
> 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