[
https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-3655:
------------------------------------------
I don't know all the details of this, but my instinct is this needs to be more
generic.
Some context: The server launch needs to be asynchronous from the thread that does the
launch so that thread has the ability to terminate the server if it hangs during boot.
Because it's asynchronous, right now in the CLI that calling thread is polling (with a
timeout) checking for the value of an address+attribute combo (differs with a server vs an
HC). That polling needs special error handling etc. It's about 40 LOC in
EmbedServerHandler, about the same in EmbedHostControllerHandler. And since it's based
on reading a particular attribute it can't work with an empty host config.
It would be better if EmbeddedManagedProcess offered a simple API for this kind of wait.
The impl of that can directly look at the ControlledProcessState; it doesn't need to
care about particular address+attribute combos that might not exist. This wait would also
be useful when handling reload.
Note that afaict the current CLI EmbedHostControllerHandler has a race when
emptyHost==true. The embed-host-controller command returns and the client is therefore
available, but the boot may not have reached RUNNING state. If the CLI user attempts to
use the client it may get failed operations.
Improve embedded HC started with empty config state reporting?
--------------------------------------------------------------
Key: WFCORE-3655
URL:
https://issues.jboss.org/browse/WFCORE-3655
Project: WildFly Core
Issue Type: Enhancement
Reporter: Ken Wills
Assignee: Ken Wills
Priority: Minor
This is a discussion ticket, and I'm really only making it to track the discussion at
the moment.
Alexey and I had a discussion regarding this, and I thought it would be useful to open
this and get other feedback.
Currently, when an embedded host controller is started with an empty config, a partial
domain controller start is performed and then paused until the /host=foo:add command is
issued.
In the case that the HC is being started programatically it seems desirable to be able to
check this step has been completed.
Using the command from the CLI / inside a cli script doesn't have this problem as the
CLI waits for the response before continuuing.
Some clients poll on the /host=foo:host-status attribute, this isn't present until a
host has been actually added though.
the existing options are:
(a) Like the CLI, just wait until the operation completes. I think this should currently
always work.
(b) Poll on the existence of the /host resource. If this is registered, then you can
safely try to add your host (after all there may already be one.)
Since the host hasn't been added, it doesn't make a lot of sense to provided a
default status, as theres no /host=foo to hold the attribute.
Other thoughts? Personally I'm a fan of (a). And I think that should always be
sufficient. I'm not really sure what the programmatic expectations are for using ops
like this are in general. Is behavior always assumed to be synchronous, so the end client
doesn't need to poll or wait etc?
[~aloubyansky] Feel free to comment and correct me if I was inaccurate about something.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)