[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2017-11-27 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267337#comment-16267337
 ] 

ASF GitHub Bot commented on SLING-6126:
---

Github user drfits closed the pull request at:

https://github.com/apache/sling/pull/180


> 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
>Assignee: Georg Henzler
> Fix For: Health Check Core 1.2.6
>
>
> 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.4.14#64029)


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-10 Thread Georg Henzler (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563989#comment-15563989
 ] 

Georg Henzler commented on SLING-6126:
--

[~drfits] Would using hc.async.cronExpression (see 
https://sling.apache.org/documentation/bundles/sling-health-check-tool.html#configuring-health-checks)
 be an option? The problem of just extending the TTL is, that users calling the 
long-running HC after a TTL has expired will not receive a result but a timeout 
(only a reload after 3-5 minutes gives an adequate result then). Using an async 
HC will never return a timeout (but always the last result).

> 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)


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-10 Thread Evgeniy Fitsner (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564657#comment-15564657
 ] 

Evgeniy Fitsner commented on SLING-6126:


Dear [~henzlerg],

Suddenly but this is not an option in my case, because we have a deployment 
every 3 weeks. After deployment DevOps should check that instance is working 
w/o errors therefore they will check "hc" 1,2,3,...,n times to validate that 
instance is working (I'm not sure how often this heavy "hc" will be executed 
but I know that  "hc" enough expensive to CPU/Memory resources, approximately 
"hc" execution time (3 min) and period in which "hc" result will be 
relevant(approximately 30min)). In case of "hc" fail between deployments we 
need to execute it once again immediately after environment repair rather than 
wait next scheduled execution.

So for case above it's OK if user try to execute "hc", then wait a little (for 
example 5 minutes to complete all "hc") and execute "hc" again - in this case 
user will see cached relevant results immediately.

In my pull request I've only added global TTL override if service contains 
HealthCheck.TTL property.

> 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)


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-11 Thread Georg Henzler (JIRA)

[ 
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=360 <-- 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)


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-13 Thread Evgeniy Fitsner (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15573362#comment-15573362
 ] 

Evgeniy Fitsner commented on SLING-6126:


Dear [~gehen],

Thanks for support but another reason why I've asked for this option in that 
I'm working with Adobe AEM and here all health checks are displaying on the 
board with status color, so user can simply check that all is green and that's 
it (simple and fast). Sure, we can every time check in console with 
"/system/console/healthcheck?tags=project_tag&overrideGlobalTimeout=5" but 
more simply to allow specify directly in class metadata special TTL value.

I've updated code in [PR|https://github.com/apache/sling/pull/180], so please 
let me know if smth else should be updated.

> 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)


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-17 Thread Georg Henzler (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583738#comment-15583738
 ] 

Georg Henzler commented on SLING-6126:
--

PR applied in revision [r1765377|http://svn.apache.org/r1765377] (with added 
JUnit test and some clean-up). Thanks for the contribution [~drfits]!

> 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
>Assignee: Georg Henzler
> Fix For: Health Check Core 1.2.6
>
>
> 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)


[jira] [Commented] (SLING-6126) Ability to specify TTL for separate health check

2016-10-18 Thread Georg Henzler (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585247#comment-15585247
 ] 

Georg Henzler commented on SLING-6126:
--

Updated documentation in [r1765377|http://svn.apache.org/r1765416]

> 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
>Assignee: Georg Henzler
> Fix For: Health Check Core 1.2.6
>
>
> 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)