Failfast / don't fail starting
Rod Widdowson
rdw at steadingsoftware.com
Mon Dec 2 11:41:16 EST 2013
What is our current design aim for fail fast?
The specific case I'm looking at is a service which needs to load (shall we
say) attribute-resolver.xml
There are four configs of interest:
1) Non faulty config file, setup is one-time (no reload)
- On start the file is loaded and off we go
2) Non faulty config file, setup is for reload
- On start the file is loaded, the refresh thread is started and off we
go.
3) Faulty config file, setup is for 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) or start the
refresh thread.
In this case the file eventually gets fixed, we reload and limp into
life. Meanwhile
All attempts to use the service (in this case attribute resolution)
will complain in the
log.
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.
/Rod
More information about the dev
mailing list