[
https://issues.apache.org/jira/browse/SLING-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806839#comment-13806839
]
Felix Meschberger commented on SLING-3207:
------------------------------------------
I agree, that in this case just getting one attribute after the other should
not retrigger executions. Having an explicit execute operations in this case
makes sense.
[~bdelacretaz] Yes, but JMX is special in a certain way: A regular health check
returns a result which can then be inspected without forcing a re-execution.
Now, thinking about it: Maybe the JMX registration should really not expose
individual details but a Result structure. This way, the Result structure can
be inspected without requiring a re-execution. Yet, this is more complicated
than just returning flat basic Java types in multiple attributes.
> Rethinking the mbean registration for health checks
> ---------------------------------------------------
>
> Key: SLING-3207
> URL: https://issues.apache.org/jira/browse/SLING-3207
> Project: Sling
> Issue Type: Improvement
> Components: Health Check
> Affects Versions: Health Check JMX 1.0.6
> Reporter: Carsten Ziegeler
> Fix For: Health Check JMX 1.0.8
>
>
> RIght now, the mbeans registered for a health check promote a set of
> attributes (status, log messages etc). Whenever a client requests the
> attributes, the health check is executed first, and the new result is
> returned.
> For one this is a little bit unexpected as requesting attributes should not
> alter the state of the mbean and secondly, there is no way to define when a
> check should be done and to get the exact same result back on two consecutive
> calls.
> I suggest that the attributes are changed to return the last result, maybe
> together with a timestamp when this result was taken and an execute method to
> actually execute the health check and update the attributes.
> This gives more control for the client while at the same time removes the
> unexpected behaviour
--
This message was sent by Atlassian JIRA
(v6.1#6144)
