I haven't thought about this yet - but I tend to agree that a health check (or someone else) needs a way to define how long a result should be cached. This could just be another service registration property as I don't think that this is a highly dynamic value which changes from execution to execution of a single HC.
I'm not so sure about timeouts by the caller - I would assume that the configured timeout for the executor is a sensible value. If you want to specify something else for a specific client, this client would need to know which HCs it's executing, how long it takes etc. We have discussed other things like forcing a HC to run (and not to use the cached value), I'm not sure about those either. We could think about adding an Options argument to the execute method where we add getter/setters for these things. But I think we need a clear result if the timeout is reached to allow clients to correctly display this and retry at a later point of time. Carsten 2014/1/3 Bertrand Delacretaz <[email protected]> > Hi, > > On Wed, Jan 1, 2014 at 4:57 PM, Georg Henzler > <[email protected]> wrote: > > ...I don't think it is that useful to be able to specify a timeout in > the web > > console HC plugin for the following reasons... > > I'm still not convinced, IMO we are very likely to need > > a) Results that don't all have the same time to live. The Health Check > that creates the result would set the TTL. > > b) Execution timeouts specified by the caller, to cope with various > types of health checks and clients > > Both are easy to add later however, so if you guys don't want to add > them now I'm fine. > > -Bertrand > -- Carsten Ziegeler [email protected]
