You have a good example here - I'm not sure though if you would really
call the health check before a spell check or if it is not better to
have good exception handling for the actual call of the spell checker if
things go wrong. What if the health check returns green and 20ms later
the service is away... the exception handling for the actual call of the
the spell check still has to be in place for this case! (making the call
to the health check beforehand really obsolete)
But let's say we want to use a health check to show a result for a tag
to the author: You still can do so with the API of the current patch of
SLING-3278:
Result result = executor.runForTags("spellchecker");
The fluent API would allow to specify timeouts or clearing the cache
per execution. I think it's better to configure TTLs and HC timeouts
once (either per check or a default globally). For instance, if you have
the spellcheck service health check: Does it really make sense to use a
different timeout for a message to the author than for the web console
used by a admin guy? The timeout is mainly influenced by typical
response times of the service, not by whom is looking at the result.
-Georg
Am 19.12.2013 19:24, schrieb Bertrand Delacretaz:
On Thursday, December 19, 2013, Georg Henzler wrote:
...The HealthCheckExecutor is only to be used by JMX and the
web console (and maybe at some point by some servlet), but not as
part of
a
normal implementation project...
That's a very limiting view.
If you have spellchecking services for example, it might be a good
idea to
expose their status to your content authors...something like
executor.forTags("spellchecker").getResult()
-Bertrand
