Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-825

JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 8.2.0.Final
    • None
    • Server
    • Hide

      1. Download jboss 7.1.1 Final zip file from
      http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.
      1.Final.zip
      2. Unzip the file into a USS directory on a z/OS system.
      3. Go to the bin subdirectory and convert two script files to
      EBCDIC using the following commands:
      iconv -f ISO8859-1 -t IBM1047 standalone.sh >startjboss.sh
      iconv -f ISO8859-1 -t IBM1047 standalone.conf >startjboss.conf
      4. Edit startjboss.sh and change reference to 'standalone.conf' to
      'startjboss.conf'
      5. Add the following statements after the first line of the
      startjboss.sh file:

      HOST=`hostname`
      export JAVA_OPTS="-Djboss.bind.address=$HOST
      -Djboss.bind.address.management=$HOST
      -Djboss.bind.address.unsecure=$HOST"

      6. Export JAVA_HOME to point to the v7r0m0 SR2 JVM
      7. Go to the standalone/configuration directory, edit
      standalone.xml in ascii mode, and make sure that the port numbers
      specified are not in use on your system.
      8. Go back to the bin directory and run ./startjboss.sh

      You would normally see the following message displayed on the terminal when JBOSS completes initialization. With the SR2 level of the JVM, you will never see this message, and you will not be able do stop the server
      with cntrl-C. It will require a kill -9 to stop the process.

      16:31:04,947 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874:
      JBoss AS 7.1.1.Final "Brontes" started in 8930ms - Started 133 of 208
      services (74 services are passive or on-demand)

      Show
      1. Download jboss 7.1.1 Final zip file from http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1 . 1.Final.zip 2. Unzip the file into a USS directory on a z/OS system. 3. Go to the bin subdirectory and convert two script files to EBCDIC using the following commands: iconv -f ISO8859-1 -t IBM1047 standalone.sh >startjboss.sh iconv -f ISO8859-1 -t IBM1047 standalone.conf >startjboss.conf 4. Edit startjboss.sh and change reference to 'standalone.conf' to 'startjboss.conf' 5. Add the following statements after the first line of the startjboss.sh file: HOST=`hostname` export JAVA_OPTS="-Djboss.bind.address=$HOST -Djboss.bind.address.management=$HOST -Djboss.bind.address.unsecure=$HOST" 6. Export JAVA_HOME to point to the v7r0m0 SR2 JVM 7. Go to the standalone/configuration directory, edit standalone.xml in ascii mode, and make sure that the port numbers specified are not in use on your system. 8. Go back to the bin directory and run ./startjboss.sh You would normally see the following message displayed on the terminal when JBOSS completes initialization. With the SR2 level of the JVM, you will never see this message, and you will not be able do stop the server with cntrl-C. It will require a kill -9 to stop the process. 16:31:04,947 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 8930ms - Started 133 of 208 services (74 services are passive or on-demand)

      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.

        1. relevant-threads.txt
          11 kB
          Brian Stansberry
        2. threadstacks.txt
          207 kB
          Bob Bennett

              jgreene@redhat.com Jason Greene
              benro02_jira Bob Bennett (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: