[JBoss JIRA] (WFLY-7710) Console does not provide an option to kill a server if normal shutdown is hung
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7710?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7710:
----------------------------------------
Oops, I spoke too soon re: current console being better than EAP 6. It seems the current console returns UI control to the user while the "stop" is proceeding in the background. During this period, the UI presents the normal actions as if the server was started. But once the "stop" operation aborts on the server side, the console shows the action list as if the server was stopped.
I think this is a separate issue and may require some server side change to better report to the console the real state of the server. But I think it's probably best to always include the "Force Shutdown" option. Force Shutdown is primarily for pathological situations and that means it's possible the HC is not clear on what the state of the server is. So just always provide it as a choice.
> Console does not provide an option to kill a server if normal shutdown is hung
> ------------------------------------------------------------------------------
>
> Key: WFLY-7710
> URL: https://issues.jboss.org/browse/WFLY-7710
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Reporter: Brian Stansberry
> Assignee: Harald Pehl
>
> I'm experimenting with how an WildFly/EAP domain reacts to failure conditions and noticed that the current console, if a server will not stop, will not provide an option to kill the server.
> My experiment involves a pathological app with a servlet that will never return from it's deplpy() method, meaning the MSC service behind the servlet will never stop, meaning a normal shutdown will never complete.
> The EAP 6 console had "Stop" and "Force Shutdown" links for the servers in the domain topology view. Current console has no "Force Shutdown".
> EAP 6 console has it's own issues in this area, specifically that if the server won't stop, the console reports it stopped anyway, and no longer provides the option to stop or force shutdown. The current console is better in this regard; when the server doesn't shut down the action selections for the server are still the same as if the server was started. So it's just the kill/destroy that is missing.
> See also related JIRA https://issues.jboss.org/browse/WFCORE-2065 for how kill/destroy are suboptimal on the server side. That's mostly an FYI in case during experiments with this you find things are not behaving as you expect.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7710) Console does not provide an option to kill a server if normal shutdown is hung
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-7710:
--------------------------------------
Summary: Console does not provide an option to kill a server if normal shutdown is hung
Key: WFLY-7710
URL: https://issues.jboss.org/browse/WFLY-7710
Project: WildFly
Issue Type: Bug
Components: Web Console
Reporter: Brian Stansberry
Assignee: Harald Pehl
I'm experimenting with how an WildFly/EAP domain reacts to failure conditions and noticed that the current console, if a server will not stop, will not provide an option to kill the server.
My experiment involves a pathological app with a servlet that will never return from it's deplpy() method, meaning the MSC service behind the servlet will never stop, meaning a normal shutdown will never complete.
The EAP 6 console had "Stop" and "Force Shutdown" links for the servers in the domain topology view. Current console has no "Force Shutdown".
EAP 6 console has it's own issues in this area, specifically that if the server won't stop, the console reports it stopped anyway, and no longer provides the option to stop or force shutdown. The current console is better in this regard; when the server doesn't shut down the action selections for the server are still the same as if the server was started. So it's just the kill/destroy that is missing.
See also related JIRA https://issues.jboss.org/browse/WFCORE-2065 for how kill/destroy are suboptimal on the server side. That's mostly an FYI in case during experiments with this you find things are not behaving as you expect.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase Failing Due To Native Protocol Issue
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2068:
-------------------------------------
Description:
The listed test case is failing during clean up with the following error: -
{noformat}
java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
{noformat}
The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
was:
The listed test case is failing during clean up with the following error: -
{noformat}
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 41.112 sec <<< FAILURE! - in org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase
org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase Time elapsed: 7.089 sec <<< ERROR!
org.jboss.as.cli.CommandLineException: The controller is not available at 127.0.0.1:9999
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:180)
at org.jboss.as.cli.impl.CLIModelControllerClient$3.getChannel(CLIModelControllerClient.java:132)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1299)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1143)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1120)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.reloadServer(HTTPSConnectionWithCLITestCase.java:175)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.resetTestConfiguration(HTTPSConnectionWithCLITestCase.java:162)
{noformat}
The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
> HTTPSConnectionWithCLITestCase Failing Due To Native Protocol Issue
> -------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
> Priority: Blocker
> Fix For: 3.0.0.Alpha14
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase Failing Due To Native Protocol Issue
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-2068:
----------------------------------------
Summary: HTTPSConnectionWithCLITestCase Failing Due To Native Protocol Issue
Key: WFCORE-2068
URL: https://issues.jboss.org/browse/WFCORE-2068
Project: WildFly Core
Issue Type: Bug
Components: Remoting, Test Suite
Reporter: Darran Lofthouse
Assignee: Jean-Francois Denise
Priority: Blocker
Fix For: 3.0.0.Alpha14
The listed test case is failing during clean up with the following error: -
{noformat}
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 41.112 sec <<< FAILURE! - in org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase
org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase Time elapsed: 7.089 sec <<< ERROR!
org.jboss.as.cli.CommandLineException: The controller is not available at 127.0.0.1:9999
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:180)
at org.jboss.as.cli.impl.CLIModelControllerClient$3.getChannel(CLIModelControllerClient.java:132)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1299)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1143)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1120)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.reloadServer(HTTPSConnectionWithCLITestCase.java:175)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.resetTestConfiguration(HTTPSConnectionWithCLITestCase.java:162)
{noformat}
The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-799) Elytron ExternalSaslServerFactory returns EXTERNAL mechanism name when Sasl.POLICY_PASS_CREDENTIALS provided
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-799?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek commented on ELY-799:
---------------------------------
The same is valid for the {{ExternalSaslClientFactory}}. Fix it in both implementations, please.
> Elytron ExternalSaslServerFactory returns EXTERNAL mechanism name when Sasl.POLICY_PASS_CREDENTIALS provided
> ------------------------------------------------------------------------------------------------------------
>
> Key: ELY-799
> URL: https://issues.jboss.org/browse/ELY-799
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> The method {{org.wildfly.security.sasl.external.ExternalSaslServerFactory.getMechanismNames(Map<String, ?>)}} returns the {{"EXTERNAL"}} name also in cases where {{Sasl.POLICY_PASS_CREDENTIALS}} property is provided with {{"true"}} value.
> Only mechanisms which actually pass credentials should be returned for such policy (unless the special {{WildFlySasl#MECHANISM_QUERY_ALL}} property is given).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-802) Elytron ExternalSaslServer/Client should throw IllegalStateException for wrap/unwrap methods
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-802?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek updated ELY-802:
----------------------------
Description:
Calling {{wrap/unwrap}} methods on {{ExternalSaslServer/Client}} should throw {{IllegalStateException}} as defines [the contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...]. Currently it throws a {{SaslException}}.
We could be inspired by OpenJDK implementation of CRAM-MD5 and do the following in both methods:
{code:java}
if (completed) {
throw new IllegalStateException(
"EXTERNAL supports neither integrity nor privacy");
} else {
throw new IllegalStateException(
"Authentication not completed");
}
{code}
was:
Calling {{wrap/unwrap}} methods on {{ExternalSaslServer}} should throw {{IllegalStateException}} as defines [SaslServer contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...]. Currently it throws a {{SaslException}}.
We could be inspired by OpenJDK implementation of CRAM-MD5 and do the following in both methods:
{code:java}
if (completed) {
throw new IllegalStateException(
"EXTERNAL supports neither integrity nor privacy");
} else {
throw new IllegalStateException(
"Authentication not completed");
}
{code}
Summary: Elytron ExternalSaslServer/Client should throw IllegalStateException for wrap/unwrap methods (was: Elytron ExternalSaslServer should throw IllegalStateException for wrap/unwrap methods)
> Elytron ExternalSaslServer/Client should throw IllegalStateException for wrap/unwrap methods
> --------------------------------------------------------------------------------------------
>
> Key: ELY-802
> URL: https://issues.jboss.org/browse/ELY-802
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> Calling {{wrap/unwrap}} methods on {{ExternalSaslServer/Client}} should throw {{IllegalStateException}} as defines [the contract|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/Sas...]. Currently it throws a {{SaslException}}.
> We could be inspired by OpenJDK implementation of CRAM-MD5 and do the following in both methods:
> {code:java}
> if (completed) {
> throw new IllegalStateException(
> "EXTERNAL supports neither integrity nor privacy");
> } else {
> throw new IllegalStateException(
> "Authentication not completed");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2066) Kill and destroy operations on the server-group
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2066:
----------------------------------------
Summary: Kill and destroy operations on the server-group
Key: WFCORE-2066
URL: https://issues.jboss.org/browse/WFCORE-2066
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
The server-config resources expose kill and destroy operations; it would be useful to have these on the server-group as well. If some problem (e.g. a bad deployment) is causing all servers in the group to hang it is nice to be able to kill/destroy them in one op versus having to identify all members and kill them individually.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2065) Domain server 'kill' and 'destroy' operations need to ensure the server is dead
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2065:
----------------------------------------
Summary: Domain server 'kill' and 'destroy' operations need to ensure the server is dead
Key: WFCORE-2065
URL: https://issues.jboss.org/browse/WFCORE-2065
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months