[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
Wed Oct 31 14:20:18 EDT 2012
[ https://issues.jboss.org/browse/AS7-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730560#comment-12730560 ]
Bob Bennett commented on AS7-5858:
----------------------------------
I downloaded latest nightly build - JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" - and still had the problem. Here are all the messages that were displayed on the terminal:
14:17:13,998 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.3.GA
14:17:14,342 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
14:17:14,472 INFO [org.jboss.as] (MSC service thread 1-7) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
14:17:16,906 INFO [org.xnio] (MSC service thread 1-10) XNIO Version 3.0.7.GA
14:17:16,915 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (man agement-http)
14:17:16,921 INFO [org.xnio.nio] (MSC service thread 1-10) XNIO NIO Implementation Version 3.0.7.GA
14:17:16,923 WARN [org.xnio.nio] (MSC service thread 1-10) The currently defined selector provider class (sun.nio.ch.PollSelectorProvid er) is not supported for use with XNIO
14:17:16,933 INFO [org.jboss.remoting] (MSC service thread 1-10) JBoss Remoting version 3.2.12.GA
14:17:17,011 INFO [org.jboss.as.configadmin] (ServerService Thread Pool -- 27) JBAS016200: Activating ConfigAdmin Subsystem
14:17:17,069 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) JBAS010280: Activating Infinispan subsystem.
14:17:17,107 INFO [org.jboss.as.security] (ServerService Thread Pool -- 46) JBAS013171: Activating Security Subsystem
14:17:17,122 INFO [org.jboss.as.osgi] (ServerService Thread Pool -- 41) JBAS011906: Activating OSGi Subsystem
14:17:17,125 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 40) JBAS011800: Activating Naming Subsystem
14:17:17,172 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 50) JBAS015537: Activating WebServices Extension
14:17:17,183 INFO [org.jboss.as.security] (MSC service thread 1-8) JBAS013170: Current PicketBox version=4.0.14.Final
14:17:17,541 INFO [org.jboss.as.connector.logging] (MSC service thread 1-10) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0. 12.Final)
14:17:17,595 INFO [org.jboss.as.naming] (MSC service thread 1-10) JBAS011802: Starting Naming Service
14:17:17,601 INFO [org.jboss.as.mail.extension] (MSC service thread 1-20) JBAS015400: Bound mail session [java:jboss/mail/Default]
14:17:17,842 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-complian t driver class org.h2.Driver (version 1.3)
14:17:18,250 INFO [org.jboss.ws.common.management] (MSC service thread 1-18) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.1.0.Final
14:17:18,734 INFO [org.apache.coyote.http11] (MSC service thread 1-14) JBWEB003001: Coyote HTTP/1.1 initializing on : http-USILCA31.CA. COM/141.202.65.31:42080
14:17:18,745 INFO [org.apache.coyote.http11] (MSC service thread 1-14) JBWEB003000: Coyote HTTP/1.1 starting on: http-USILCA31.CA.COM/1 41.202.65.31:42080
14:17:18,862 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-16) JBAS010400: Bound data source [java:jboss/d atasources/ExampleDS]
14:17:18,870 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-18) JBAS015012: Started FileSystemDeploymentService fo r directory /u/users/costopt/jboss7/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/deployments
I will attempt to attach the javacore file, which contains the stack traces of all the active threads.
> 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
>
> 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