[
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565227#comment-15565227
]
Georg Henzler commented on SLING-6126:
--------------------------------------
If it is a DevOps Setup that checks for the health of an instance after
deployment, probably it's better to first call
/system/health/regularcheckstag.txt <-- returns quickly for the case something
basic went wrong
and then
/system/health/longrunningchecktag.txt?timeout=3600000 <-- this can be waited
for synchronously and will return exactly after the long running check is
finished.
Would that work for you? If not, I'm not opposed to add the TTL config setting
for individual HCs (see my comments in PR), just questioning if it really
provides value or just adds additional complexity.
> Ability to specify TTL for separate health check
> ------------------------------------------------
>
> Key: SLING-6126
> URL: https://issues.apache.org/jira/browse/SLING-6126
> Project: Sling
> Issue Type: Improvement
> Components: Health Check
> Reporter: Evgeniy Fitsner
>
> Currently there is no ability to specify TTL for separate health check.
> Ex.: in my case "hc" validating against repository about 3-5 minutes
> therefore I couldn't specify TTL globally to not impact on other "hc"
> results. This "hc" I couldn't execute by scheduler to prevent CPU from high
> loading, also results for this check remains relevant for an 1-3 hours.
> Therefore if it make sense not only for me I've added "[pull
> request|https://github.com/apache/sling/pull/180]"; for this functionality:
> * If property "hc.ttl" specified within HC - it will be used as TTL for
> result, otherwise cache will use default TTL value
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
