Failfast / don't fail starting

Tom Zeller tzeller at dragonacea.biz
Mon Dec 2 13:09:14 EST 2013


>>What is our current design aim for fail fast?
>
> My opinion on this is pretty well known: I don't believe in it. I think
> you produce as functional a state as possible and log the rest.
>
> I am ok with having flags for that, but as far as defaulting, I think most
> people end up confused by fail fast, and I think a case can be made for
> flipping the default in 3.0 if others share my view.

I'm okay with defaulting to non-fail-fast.

>>4) Faulty config file, setup is for no reload.
>>
>>  - On start the file fails to load and we complain bitterly in the log.
>>      The IdP has the option to stop immediately (fail fast).
>>      We do have the option to spin up a reload thread with default timing
>>to allow things
>>      to reload when the config is fixed.  At this stage however the
>>service
>>is in auto-reload
>>      mode which might be a bad idea.  Fixing this would require even more
>>difficult to explain
>>      configuration or special purpose code.
>>
>>Obviously case (4) is the one which is of most interest to me right now.
>
> I don't think we need complicate life by making it possible to configure
> non-fail-fast behavior without reloading, and yet have somebody expect it
> will reload.

I think no-reload means no-reload, so maybe log a suggestion to turn
on reloading to deal with the faulty config.


More information about the dev mailing list