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.