[
https://issues.apache.org/jira/browse/SLING-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852998#comment-13852998
]
Georg Henzler commented on SLING-3278:
--------------------------------------
Re Fluent API as well as "The class name is implementation detail, no one knows
it": I think we have a disconnect in how we think the health check executor
could/should be used. I think implementation projects really only want to be
able to add checks and run them via web console or JMX, they would never want
to execute the checks in a custom fashion other than configuring timeouts or
restricting it to certain tags (also see mailing list post). @Carsten / 1): I
think you need the run(hc-class) mainly for the JMX module: Don't you have
access to the classname via the property component.name there? The problem with
the name is that it may contain spaces and therefore is not really a nice id
for using it as a parameter?
2) The ExecutionResult is a good idea - that way all timing data can go there.
Also, Execution Result should be an interface and ExecutionResultImpl can be
hidden in the impl.executor package - that way ExecutionResultImpl does not
have to be immutable and the timing data can be collected correctly (also
solving Bertrands concerns).
3) If we create the interface ExecutionResult, we can hide the existence of the
HealthCheckDescriptor and move it to impl.executor. The field serviceReference
can be marked transient and is therefore be taken out from Serialization (if
that really ever is needed, I think probably not)
> Provide a HealthCheckExecutor service
> -------------------------------------
>
> Key: SLING-3278
> URL: https://issues.apache.org/jira/browse/SLING-3278
> Project: Sling
> Issue Type: New Feature
> Components: Health Check
> Reporter: Georg Henzler
> Assignee: Georg Henzler
> Attachments: SLING-3278-bertrand.patch,
> SLING-3278-hc.core-HealthCheckExecutorService-2013-12-19.patch,
> SLING-3278-hc.webconsole-2013-12-19.patch, hc-it.patch
>
>
> Goals:
> * Be able to get an overall (aggregated) result as quickly as possible
> (ideally <2sec)
> * Whenever possible, return most current results (e.g. for a memory check)
> * Provide a declarative way for async checks (async checks should be the
> exception though)
> Approach
> * Run checks in parallel
> * Make sure long running (or even stuck) checks are timed out
> * If a health check must run asynchronously (because its execution time
> cannot be optimized), it should be enough to just specify a service property
> (e.g. "hc.async").
> See also
> http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402
> http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
