[jboss-jira] [JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539078#comment-13539078 ] 

Brian Stansberry commented on WFCORE-3655:
------------------------------------------

[~luck3y] I believe polling for any successful read (e.g. of an attribute on the root resource) would work as a workaround to prevent the race I mentioned. The WFCORE-2579 fix at https://github.com/wildfly/wildfly-core/pull/3124 means any op from the embedded client fails during boot until the process reaches RUNNING state.  IOW, simply successfully executing an op provides the same info as reading a particular attribute.

> 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)