Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-7632

[GSS](7.0.z) Domain server 'kill' and 'destroy' operations need to ensure the server is dead

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.0.5.CR1, 7.0.5.GA
    • None
    • Management
    • None
    • EAP 7.0.5

      This is part of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1259767 which is scheduled for 6.4 CP13 and hence needs to go into 7.0.z as well.

      The 'kill' and 'destroy' operations end up triggering invocation of the ManagedProcess kill() and destroy() methods. But those methods don't ensure the server process ends up dead. Their primary code path is to call 'stop()' and return. But if there is a problem doing the normal stop (which is fairly likely given the user invoked 'kill' or 'destroy' then the server process is left hanging around as a zombie.

      A second invocation of kill or destroy will end up doing the real kill/destroy by realizing the stop() hasn't worked, but that is unintuitive and inconvenient.

      Worse, with the EAP 6 web console at least, the console reports the process as being down, which is highly misleading, and it means the console doesn't provide the UI elements to allow the user to try again. The user is forced to use the CLI to do the second kill/destroy.

      I think these methods should try the stop() but then after 5-10 seconds if the process isn't down, go on and invoke the hard kill/destroy logic. Assume that the user chose kill/destroy over stop for a reason and that a normal stop not succeeding quickly means stronger action is needed. The only downside to this is some server that could stop normally but happens to take a bit too long is hard killed, but that to me is a real edge case.

            bstansbe@redhat.com Brian Stansberry
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: