camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Huss (JIRA)" <>
Subject [jira] [Commented] (CAMEL-10795) PingCheck API
Date Fri, 10 Feb 2017 11:33:41 GMT


Roland Huss commented on CAMEL-10795:

Looks good to me in general. Some remarks:

* Maybe {{validate()}} is a bit better than {{vaildateOptions()}} ? Since it might be also
that a connection fails even when the options are valid (because the targeted backend has
issues at the moment). Hmm, maybe even 'validate' does not catch this use case (where the
options are valid, but still a connection test fails). Maybe {{check()}} or {{test()}} does
fit better ?
* Should it be possible to provide a aggregate scope like "all" ? If so, then the result needs
to be an aggregation, too, with individual result for each check.
* If a scope of "connectivity" is provided, but the component can't check the connectivity
because the "parameters" are not valid, shouldn't this be reflected in the return value, too

On a second thought, I'm not sure now whether we should stuff all these use cases in a single,
general purpose method, because I see some quite orthogonal use cases:

* Validate whether a set of configuration options is syntactically valid ({{validate(Map opts)}})
* Check whether a connection is possible ({{test(Map opts)}}). Valid options are a prerequisite
for this.
* Use {{test()}} it for health-checks. For this use case it would be awesome if the result
could contains also some metrics (e.g. how long the connection took).

still in brainstorming mode ;-)

> PingCheck API
> -------------
>                 Key: CAMEL-10795
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Claus Ibsen
>             Fix For: 2.19.0
> Related to CAMEL-10026 about Health Check API
> We need some way for Camel components to be able to more easily validate if they can
connect to their remote system.
> And for that the user must configure the Camel component/endpoint accordingly with details
such as username/password/tokens/ other beans etc.
> How this is done varies from Camel component to component, but most of them uses endpoint
> So we may want to introduce some interface (whether the name Pingable is a good name
is up for discussion)
> {code}
> interface Pingable {
>     PingResult ping(Map<String, String> config);
>     boolean canPing(Map<String, String> config);
> }
> class PingResult {
>  private boolean isSuccess();
>  private String errorMessage();
> }
> {code}
> This API is just a little suggestion.
> The parameters should ideally be type less, eg Map<String, String> as the user
configures this in endpoint uris, XML DSL etc. and therefore we should be able to do this
without having to use Java code per see.
> Also we may want to have canPing as a method to check if the component can accept the
ping or not. In some cases it may not be able to do the ping.
> For example camel-http component would just require the following information in the
Map<String, String>
> httpUri=http://myserver/foo/bar
> Where httpUri is the name of the option accordingly to the table at
> And then it depends on each Camel component how they do the ping check, the http component
may do a HTTP HEAD or a HTTP GET etc and check the HTTP response code etc.
> Notice this is not intended entirely for runtime health check, but for validating/testing
Camel components can work with the user given configuration to connect to the remote system.

This message was sent by Atlassian JIRA

View raw message