When using the native management api, calls to commandContext.disconnectController() do not cause all threads to be killed, which causes the application to hang, instead of exiting. This is fixed in WildFly: https://github.com/jaikiran/wildfly/commit/dc3f3b4492e89cd7f97d48ab08d6a4869708da90 This BZ is for backporting to EAP 6.x
pull request done: https://github.com/jbossas/jboss-eap/pull/239
corrected pull request: https://github.com/jbossas/jboss-eap/pull/240
Thanks for the release notes draft Tom. We need a bit more information to complete the text (questions marked in square brackets below): Cause: When using the native management api, calls to commandContext.disconnectController() do not cause all threads to be killed. [Why didn't the disconnectController kill the threads? This cause is actually part of the consequence.] Consequence: This meant calls to commandContext.disconnectController() did not kill all threads which caused the application to hang, instead of exiting. Fix: In this version of EAP 6, affected threads are started as deamons [why does this solve the problem? Are deamons killed in a different way?] Result: The result is that threads get killed as expected, allowing the application to exit normally.
I think this is better now.
Verified on EAP 6.1.1 ER4
Have added a new version of the release notes draft. Setting NEEDINFO to request verification for technical accuracy.
Marking for exclusion from the 6.1.1 Release Notes document as an entry for this bug could not be completed or verified in time.