-
1. Re: Blocking on Admin "reload configuration" operation
jaikiran Jul 8, 2013 6:12 AM (in response to alrubinger)Hi Andrew,
You can add:
reloadOperation.get("blocking").set(true);
before executing the operation.
-
2. Re: Blocking on Admin "reload configuration" operation
alrubinger Jul 8, 2013 6:52 AM (in response to jaikiran)Thanks, Jaikiran:
Unfortunately, this doesn't do the trick. From the logs:
Reload config op returned
ESC[0m06:50:21,861 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS018224: Unregister web context
: /hornetq-server
ESC[0mESC[0m06:50:21,864 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017521: Undertow HTTP li
stener default suspending
...this shows that the logging message I've added after executing the config is hit *before* the server starts to unregister things and reload config before coming back up again. Any other ideas?
S,
ALR
-
3. Re: Blocking on Admin "reload configuration" operation
brian.stansberry Jul 8, 2013 10:15 AM (in response to alrubinger)Please explain more about what you are trying to do. It's not clear to me exactly where you want things to block.
-
4. Re: Blocking on Admin "reload configuration" operation
alrubinger Jul 8, 2013 10:29 AM (in response to brian.stansberry)Sure, thanks Brian.
Submitting the request:
client.execute(reloadOperation)
;..blocks until a success response is received from the server. However, that response is returned *before* the server carries out the reloading of the configuration, which brings down the running services and then boots back up again. I need to block on the full reload of the server, not obtaining the response from the "execute" call.
S,
ALR
-
5. Re: Blocking on Admin "reload configuration" operation
brian.stansberry Jul 8, 2013 2:13 PM (in response to alrubinger)OK, thanks; from your previous post showing logging I wasn't sure whether you were trying to do something complex with a composite operation with steps in the composite executing after the reload step.
This is something that needs to be handled on the client side, as the reload basically removes everything on the server side.
Alexey poked into internals to add some custom handling for this into the CLI client for the AS 7.2 high level "reload" command. There was discussion about making some of that logic more generally usable. I'll ping Alexey and Emanuel to see where that stands. When the reload happens, the connection to the client gets closed, so the client has to deal with that and then try to reconnect. Race conditions abound.
The blocking=true param is only for some of operations exposed by a managed domain HostController, e.g. /host=hosta/server=server1:reload. In that case the HC is in the middle handling the operation and handles blocking waiting for the server to reload and reconnect.
-
6. Re: Blocking on Admin "reload configuration" operation
aloubyansky Jul 8, 2013 3:18 PM (in response to brian.stansberry)There are a few race conditions possible. For the reload operation the user might not even receive the outcome "success", as the service/connection shutdown could take over the response handling which would result in "Channel closed" exception or something like that.
I am not aware of any work being done to make it more generally usable. The CLI is relying on remoting3 api (specifically, its connection state change notifications) and custom re-connect logic, while ideally it should use only the protocol module of the AS w/o any assumptions about what's used underneath. I remember this was the point: not to expose remoting3 api to the management clients.
What CLI does is basically it is blocking until the connection to the controller is shutdown and then after a short pause it is trying to reconnect in a loop with an interval. Once the connection is established (or a timeout is reached), it returns the control back to the client. But that's true only for the reload and shutdown commands, not :reload and :shutdown operations.
-
7. Re: Blocking on Admin "reload configuration" operation
alrubinger Jul 8, 2013 6:03 PM (in response to aloubyansky)Thanks for this background, gentlemen.
An approach I'm considering conceptually: attempt reconnects to the ModelControllerClient in a loop with timeouts until success; does creation of a new ModelControllerClient block until it can obtain a connection? Or just allocate the instance and store the target host URI/port as metadata? Could you link me to the relevant CLI code you mention, Alexey?
S,
ALR
-
8. Re: Blocking on Admin "reload configuration" operation
brian.stansberry Jul 8, 2013 6:26 PM (in response to alrubinger)The handling of a reload within the CLI:
The issue there is the CLI is using a custom impl of ModelControllerClient in order to get notifications from the jboss-remoting layer and to support checking and ensuring the connection status:
-
9. Re: Blocking on Admin "reload configuration" operation
emuckenhuber Jul 9, 2013 9:57 AM (in response to alrubinger)One thing we plan on doing is to create a separate management client (outside of WF) which implements the current protocol, however you'd get a management connection instead of a stateless client. So when executing a reload operation you'd wait for the connection being closed before trying to reconnect. Currently it's not clear when that is going to happen though, so doing something like the cli controller-client (or TestControllerClient in the testsuite) is probably your best option for now.
-
10. Re: Blocking on Admin "reload configuration" operation
alrubinger Jul 9, 2013 3:02 PM (in response to brian.stansberry)Thank you; I'll likely aim to provide something similar to the usage here.
-
11. Re: Blocking on Admin "reload configuration" operation
brian.stansberry Jul 10, 2013 1:26 PM (in response to alrubinger)A thought I've had on this general topic is that org.jboss.as.arquillian.container.ManagementClient should expose a reload() method to encapsulate some of this for tests, the way the CLI high-level command does for CLI users. Some of the internal stuff that CLIModelControllerClient deals with would still have to be fixed, but ManagementClient is responsible for creating its own ModelControllerClient, so at least that stuff would be a hidden implementation detail.
There are various hacks of handling reload in the WF testsuite that need to be replaced with something robust.
-
12. Re: Blocking on Admin "reload configuration" operation
alrubinger Jul 10, 2013 2:29 PM (in response to brian.stansberry)That's a Good Idea. Once I have https://github.com/arquillian/continuous-enterprise-development/issues/66 resolved, I can port the solution into the ARQ Container adaptor in the Management Client.
OT: We broke the Arquillian Container adaptor out of AS7/WF codebase as we'd discussed awhile back. So now there's a fork situation going on - the one we have and the one currently in the WF repo. Very soon we'll need to resolve this, as there are a series of issues that need attention: https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20component%20%3D%20%22Test%20Suite%22%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20alrubinger%20ORDER%20BY%20priority%20DESC
S,
ALR