[keycloak-dev] server start up errors

[John Dennis]

On 06/21/2016 09:34 AM, Bill Burke wrote:
>
>
> On 6/21/16 8:21 AM, John Dennis wrote:
>>
>> The "wait for full initialization" problem is not new to us with
>> daemons. It's come up a number of times with IPA and other daemons we
>> work with. The way we've dealt with it is to have our service scripts
>> that start and stop services write to one of the primary sockets and
>> only when it gets a valid response back conclude the service is in fact
>> up (handling timeouts of course). Systemd came along later and might
>> have some support for socket detection, I'll investigate that option.
>>
>
> This is good feedback.  I'm not sure what you mean by writing to a
> primary socket.  You mean HTTP(S) 80/443?  I'm pretty sure HTTP(S)
> sockets are set up before Keycloak is even deployed.  This is because
> internally Keycloak has a dependency on HTTP subsystem and won't be
> initialized until that subsystem is started.

Sorry, I guess I wasn't clear. What I meant was to send a request and 
wait for a valid response. It makes sense the servlet container would 
have it's listening sockets set up much earlier but Keycloak won't 
respond to a request on a valid endpoint until it's fully initialized.

What I was trying to describe was something like this, a loop iterates 
trying to send a request, it ignores common socket errors, if a valid 
response is received it terminates the loop with a success status. If 
after a specified time interval or iteration count a valid response has 
not been received it terminates the loop with a failure status.

Of course this means there is some endpoint which does not require 
authentication nor has any side-effect. I'm guessing the REST API 
exposes something which could be used for this purpose but I haven't 
looked into it.

> Can you parse System output for a specific string?  Is that viable?
> I'll ping Wildfly team to see how they've handled stuff like this.

Trying to parse the log is problematic. Normally the log is appended to 
(until log rotation occurs). It could be tricky to identify the matching 
log message associated with the server lifetime. Also in some scenarios 
log messages may not be flushed immediately, especially if logging is 
configured to go to a network location. It also would make the service 
script dependent on knowing the logging configuration and exact messages 
to look for which may change between versions, a maintenance issue.


-- 
John