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