glassfish
  1. glassfish
  2. GLASSFISH-20464

Timeout when stop the domain with --force=false after deployed the ejb application

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0_b87_RC3
    • Fix Version/s: 4.1.1
    • Component/s: orb
    • Labels:
      None
    • Environment:

      All

      Description

      I have found a strange situation that it will be timeout if I stop the DAS or instance with -force=false after I have deployed an ejb application. Here's my reproduced steps:

      1). asadmin start-domain

      2). asadmin deploy Hello.jar
      Application deployed with name Hello.
      Command deploy executed successfully.

      3). asadmin stop-domain -force=false
      Waiting for the domain to stop .......................................
      Timed out (60 seconds) waiting for the domain to stop.
      Command stop-domain failed.

      4).jstack jvm_pid > jstack.txt(I have attached the jstack file).

      5). asadmin start-domain
      Waiting for domain1 to start .Error starting domain domain1.
      The server exited prematurely with exit code 1.
      Before it died, it produced the following output:

      FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_E
      RROR_TRANSPORT_INIT(197)
      ERROR: transport error 202: bind failed: Address already in use
      ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
      JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../.
      ./../src/share/back/debugInit.c:750]

      Command start-domain failed.

      Then the domain can't be start normally, I think somewhere must lock the file because of deploy the ejb application. But I don't the exactly reason about this.

      BTW: <1>. The exception will not come out if we stop the domain or cluster with default option of -force.
      <2>. The exception will not come out if stop the DAS and cluster after only deployed the web application.

        Activity

        Hide
        Jeremy_Lv added a comment -

        Hi, Tom

        Hers's the detailed informations about my ejb application

        HelloWorld.java
        package clchun.ejb3.Impl;
        
        import javax.ejb.Stateless;
        import clchun.ejb3.HelloWorld;
        
        @Stateless
        public class HelloWorldBean implements HelloWorld {
            public String Say(String name){
                return name + "Say: Hello World";
            }
        }
        
        HelloWorld.java
        package clchun.ejb3;
        
        import javax.ejb.Remote;
        
        @Remote
        public abstract interface HelloWorld
        {
          public abstract String Say(String paramString);
        }
        

        There's no other file except the above two class file

        Show
        Jeremy_Lv added a comment - Hi, Tom Hers's the detailed informations about my ejb application HelloWorld.java package clchun.ejb3.Impl; import javax.ejb.Stateless; import clchun.ejb3.HelloWorld; @Stateless public class HelloWorldBean implements HelloWorld { public String Say( String name){ return name + "Say: Hello World" ; } } HelloWorld.java package clchun.ejb3; import javax.ejb.Remote; @Remote public abstract interface HelloWorld { public abstract String Say( String paramString); } There's no other file except the above two class file
        Hide
        Tom Mueller added a comment -

        The non-daemon thread that shows up in the jstack output in this case is:

        "Thread-30" prio=6 tid=0x34584800 nid=0xb28 in Object.wait() [0x33ddf000]
        java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:503)
        at com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive.run(Util.java:818)

        • locked <0x12130ba8> (a com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive)
        Show
        Tom Mueller added a comment - The non-daemon thread that shows up in the jstack output in this case is: "Thread-30" prio=6 tid=0x34584800 nid=0xb28 in Object.wait() [0x33ddf000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:503) at com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive.run(Util.java:818) locked <0x12130ba8> (a com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive)
        Hide
        Tom Mueller added a comment -

        Assigning to the orb component based on the CORBA reference in the non-daemon thread stack trace.
        Please evaluate whether this is a stopper for 4.0.

        Show
        Tom Mueller added a comment - Assigning to the orb component based on the CORBA reference in the non-daemon thread stack trace. Please evaluate whether this is a stopper for 4.0.
        Hide
        Harshad Vilekar added a comment -

        This is not a stopper for 4.0.

        When the remote app is deployed, ORB is initialized, which starts the KeepAlive thread in non daemon mode. That's the current design. The default stop-domain command takes care of terminating this thread.

        With "--force=false" option, the thread is never terminated during shutdown process, and is keeping the VM from existing. There are two options to work around this:

        1. use the default stop-domain command without "--force=false" flag.

        2. undeploy all remote apps, restart the domain to shutdown the ORB, and then try "stop-domain --force=false"

        Possible resolution is to register a shutdown hook, and write a call back method to terminate KeepAlive thread, and clean up any other ORB resources. This needs further evaluation.

        Show
        Harshad Vilekar added a comment - This is not a stopper for 4.0. When the remote app is deployed, ORB is initialized, which starts the KeepAlive thread in non daemon mode. That's the current design. The default stop-domain command takes care of terminating this thread. With "--force=false" option, the thread is never terminated during shutdown process, and is keeping the VM from existing. There are two options to work around this: 1. use the default stop-domain command without "--force=false" flag. 2. undeploy all remote apps, restart the domain to shutdown the ORB, and then try "stop-domain --force=false" Possible resolution is to register a shutdown hook, and write a call back method to terminate KeepAlive thread, and clean up any other ORB resources. This needs further evaluation.
        Hide
        Tom Mueller added a comment -

        Another possible resolution may be to call Thread.setDaemon(true) on the thread after it is created. Then there is no need for a shutdown hook.

        Show
        Tom Mueller added a comment - Another possible resolution may be to call Thread.setDaemon(true) on the thread after it is created. Then there is no need for a shutdown hook.

          People

          • Assignee:
            Harshad Vilekar
            Reporter:
            Jeremy_Lv
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: