On Tue, Jan 14, 2014 at 3:49 PM, Carsten Ziegeler wrote:
> Adding a value to the enum would be a change in the api, which I would like
> to avoid.
ok, let's stay with boolean hasTimedOut() as is now.
-Bertrand
Adding a value to the enum would be a change in the api, which I would like
to avoid.
And if you're just interested if execution is successful, returning a warn
looks like a good idea to me.
Carsten
2014/1/14 Bertrand Delacretaz
> On Tue, Jan 14, 2014 at 3:34 PM, Carsten Ziegeler
> wrote:
> >
On Tue, Jan 14, 2014 at 3:34 PM, Carsten Ziegeler wrote:
> ...what about adding a boolean method, hasTimedOut() instead and always
> return a correct date?...
why not but then hasTimedOut() really means "no result available" so
isn't the NO_RESULT status that we discussed earlier clearer and
simp
Hmm, that doesn't look right to me - in that case I would need to compare
the date with an (arbitrary) fixed value.
I see the point for the null check
So what about adding a boolean method, hasTimedOut() instead and always
return a correct date?
Carsten
2014/1/14 Bertrand Delacretaz
> Hi,
>
>
Hi,
On Fri, Jan 10, 2014 at 3:57 PM, Carsten Ziegeler wrote:
> ...the interesting case still is b) - I see the point that we return WARN
> in that case - I would assume that getElapsedTimeInMs returns -1 and
> getFinishedAt() returns null. So both could be used as an indicator for
> this situatio
Answering my own question, I think its good if we always return the elapsed
time, but return null for getFinishedDate.
I'll do the change
Carsten
2014/1/10 Carsten Ziegeler
> I'Ve done the suggested changes:
> - moved jmx stuff into the core
> - changed the signature to execute(String... tags
I'Ve done the suggested changes:
- moved jmx stuff into the core
- changed the signature to execute(String... tags)
- Added service reference to metadata
The only thing I'm unclear with are the different result possibilites. I
think there are these cases when execute is called:
a) no result in the
Hi,
I think this looks pretty good now! Thanks for adding
HealthCheckMetadata :)
1. "b) merge the jmx implementation into the core"
I'm happy with that and the signature execute(String ... tags) is my
preferred
2. Status NO_RESULT
I think it's probably cleaner to add a property hasTimedOut
Yes, I would prefer a separate state, parsing the log is too error prone.
Carsten
2014/1/3 Bertrand Delacretaz
> Hi,
>
> On Fri, Jan 3, 2014 at 3:28 PM, Carsten Ziegeler
> wrote:
> > Bertrand wrote:
> >> As is you can compute the age of a result, that should already help.
> >>
> > Hmm and wha
Hi,
On Fri, Jan 3, 2014 at 3:28 PM, Carsten Ziegeler wrote:
> Bertrand wrote:
>> As is you can compute the age of a result, that should already help.
>>
> Hmm and what about the case, where there is no result yet and the HC takes
> longer than the timeout?
In my prototype I returned an HEALTH_CH
2014/1/3 Bertrand Delacretaz
> Hi,
>
> On Fri, Jan 3, 2014 at 2:12 PM, Carsten Ziegeler
> wrote:
> > ...I'm not so sure about timeouts by the caller - I would assume that the
> > configured timeout for the executor is a sensible value. If you want to
> > specify something else for a specific cli
Hi,
On Fri, Jan 3, 2014 at 2:12 PM, Carsten Ziegeler wrote:
> ...I'm not so sure about timeouts by the caller - I would assume that the
> configured timeout for the executor is a sensible value. If you want to
> specify something else for a specific client, this client would need to
> know which
I haven't thought about this yet - but I tend to agree that a health check
(or someone else) needs a way to define how long a result should be cached.
This could just be another service registration property as I don't think
that this is a highly dynamic value which changes from execution to
execut
Yes, only a single execute method with the tags.
Carsten
2014/1/3 Bertrand Delacretaz
> Hi Carsten,
>
> On Fri, Jan 3, 2014 at 9:22 AM, Carsten Ziegeler
> wrote:
> > ...I think it makes sense to move the
> > jmx stuff into the core, this keeps the executor service interface
> cleaner
>
>
Hi,
On Wed, Jan 1, 2014 at 4:57 PM, Georg Henzler
wrote:
> ...I don't think it is that useful to be able to specify a timeout in the web
> console HC plugin for the following reasons...
I'm still not convinced, IMO we are very likely to need
a) Results that don't all have the same time to live.
Hi Carsten,
On Fri, Jan 3, 2014 at 9:22 AM, Carsten Ziegeler wrote:
> ...I think it makes sense to move the
> jmx stuff into the core, this keeps the executor service interface cleaner
So IIUC if we move jmx into core the HealthCheckExecutor would have just
Collection execute(String ... t
If I look at the use cases, we have either executing HCs based on tags or
the JMX support which executes single HCs. For the jmx stuff we need to
pass the service reference into the executor - for all other use cases,
just providing the tags is sufficient.
So basically we have two options:
a) keep
I updated the wiki page at
https://cwiki.apache.org/confluence/display/SLING/Health+Checks+Executor+Design
with API Variant B: It is mostly in line with the current version in
SVN with the two changes I already suggested. Carsten, WDYT?
That might work...OTOH I want to have the execution t
Hi Carsten,
If - for whatever reason - I have an arbitrary set of HCs to execute
in
parallel, this is not possible atm. So what about having just a
single
method?
execute(ServiceReference[] hcs)
This is an option, but I would at least add the convenience method
execute(String... tags)
t
Hi Bertrand,
2013/12/31 Bertrand Delacretaz
>
>
> I don't understand why the service object cannot be used as a key.
>
First of all you would have to use an identity map as you can't expect that
the HC implements equals/hashCode correctly. But more important you don't
know how the HC service i
On Tue, Dec 31, 2013 at 11:18 AM, Georg Henzler
wrote:
> My cwiki username is henzlerg...
ok, you should have write access now.
>...IMHO caching with short TTLs is
> totally fine for use case C) as well...
That might work...OTOH I want to have the execution timeout specified
in the execute call
Hi Bertrand,
thanks for creating the Wiki Page, I suppose this is a good way to get
to a common understanding. My cwiki username is henzlerg.
Once you grant access to my user I'd like to create API Variant B and
slightly change use case C) - IMHO caching caching with short TTLs is
totally f
Hi Georg,
thanks for the explanation - I see your point of parallel execution, but :)
right now this is either executing all checks in parallel or based on tags.
If - for whatever reason - I have an arbitrary set of HCs to execute in
parallel, this is not possible atm. So what about having just a
Hi Carsten,
On Tue, Dec 24, 2013 at 11:11 AM, Carsten Ziegeler wrote:
> ...It's not just about the metadata - it's about uniquely identifying a HC
> within the executor - the service object is not a good key, especially as
> we have no way to discard it from the cache...
I don't understand why t
Hi,
On Mon, Dec 30, 2013 at 3:58 PM, Georg Henzler
wrote:
> ...now I'm afraid we might go a step backward... some things that you suggest
> to be unnecessary are essentially important from my point of view -
> supported by one year experience getting to this stage...
Yes, it seems like we have s
Hi Betrand and Christian,
now I'm afraid we might go a step backward... some things that you
suggest to be unnecessary are essentially important from my point of
view - supported by one year experience getting to this stage :). Here
are my explanations:
--- RE: executeXXX Methods
We defini
Le 30 déc. 2013 10:30, "Carsten Ziegeler" a écrit :
>
> The more I think about it, the more I get the feeling that if we can't
away
> with execute(ServiceReference) in the executor api, this should be the
only
> method of that service...
That's what my SLING-3278-bertrand.patch does, attached to
The more I think about it, the more I get the feeling that if we can't away
with execute(ServiceReference) in the executor api, this should be the only
method of that service.
The two others can easily be replaced by using the HCFilter and then
calling the method above for each service reference. I
2013/12/27 Bertrand Delacretaz
> Hi Carsten and Georg,
>
> I was going to say that I still disagree, but being outnumbered I'd
> let it go if it's just about a single method that I don't like...and
> then I reviewed the org.apache.sling.hc.api package once again and
> it's worse than I thought.
>
Hi Carsten and Georg,
I was going to say that I still disagree, but being outnumbered I'd
let it go if it's just about a single method that I don't like...and
then I reviewed the org.apache.sling.hc.api package once again and
it's worse than I thought.
You guys both say you don't want metadata in
I agree, I would definitely not force implementors to provide the
method HealthCheck.getMetadata() - I believe it's rarely a good idea to
provide meta data programmatically (if we really wanted to have a unique
ID, we could add it as service properties like the name or the tags).
Additionally,
It's not just about the metadata - it's about uniquely identifying a HC
within the executor - the service object is not a good key, especially as
we have no way to discard it from the cache. The service reference or the
service id contained within the reference is a good key. And uniquely
identifyi
Hi,
About SLING-3278 - IMO execute(ServiceReference) at [1] is an
unnecessary leak of implementation details, it makes no sense at the
API level. It's HealthChecks that we are executing, not service
references.
IIUC the root cause is that the HealthCheck API doesn't provide
metadata that it shoul
33 matches
Mail list logo
