[jira] [Commented] (CAMEL-11600) camel-micrometer - Add support for micrometer for metrics capture
[ https://issues.apache.org/jira/browse/CAMEL-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456589#comment-16456589 ] christian ohr commented on CAMEL-11600: --- also see [https://github.com/micrometer-metrics/micrometer/issues/410.] Started working on a fork branch. > camel-micrometer - Add support for micrometer for metrics capture > - > > Key: CAMEL-11600 > URL: https://issues.apache.org/jira/browse/CAMEL-11600 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > > Look at using http://micrometer.io/ > We can do something similar to camel-metrics which uses the dropwizard > library. > Then we can make it pluggable so it can be setup to do timings of Camel > routes how long time it takes to process exchanges and so on. > We can possible make it as plugable as you just add camel-micrometer on the > classpath and its auto enabled. Like we do for camel-fastermap etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456513#comment-16456513
]
Luca Burgazzoli commented on CAMEL-10793:
-
service component may be also useful to clearly state which route should be
exposed and what not
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456311#comment-16456311
]
Willem Jiang commented on CAMEL-10793:
--
+1 for the DiscoverableService interface, and we may need a common solution for
look up the address like 0.0.0.0.
Now I'm think if we can use some annotation (with the aspect advise) in the
Route to minimize the configuration (we don't even need to create the service
component for wrapping the service).
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456251#comment-16456251
]
Luca Burgazzoli edited comment on CAMEL-10793 at 4/27/18 11:25 AM:
---
Maybe we can introduce something like RegistrationConfiguration so one van use
it as ref like:
{code}
from(“service:...?serviceId=myservice=#myConfig”)
{code}
So we can have a global/sharable config that the service component can
eventually override using uri options.
Let me work on a POC next week.
was (Author: lb):
Maybe we can introduce something like RegistrationConfiguration so one van use
it as ref like:
{code}
from(“service:...?serviceId=myservice=#myConfig”)
{code}
So we can have a global/sharable config that the service component can
eventually override using uri options.
Let me work on a POC next week.
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456251#comment-16456251
]
Luca Burgazzoli edited comment on CAMEL-10793 at 4/27/18 11:24 AM:
---
Maybe we can introduce something like RegistrationConfiguration so one van use
it as ref like:
{code}
from(“service:...?serviceId=myservice=#myConfig”)
{code}
So we can have a global/sharable config that the service component can
eventually override using uri options.
Let me work on a POC next week.
was (Author: lb):
Maybe we can introduce something like RegistrationConfiguration so one van use
it as ref like:
from(“service:...?serviceId=myservice=#myConfig”)
So we can have a global/sharable config that the service component can
eventually override using uri options.
Let me work on a POC next week.
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456251#comment-16456251
]
Luca Burgazzoli commented on CAMEL-10793:
-
Maybe we can introduce something like RegistrationConfiguration so one van use
it as ref like:
from(“service:...?serviceId=myservice=#myConfig”)
So we can have a global/sharable config that the service component can
eventually override using uri options.
Let me work on a POC next week.
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12472) Downloading a large file with streamDownload and stepwise hangs
[
https://issues.apache.org/jira/browse/CAMEL-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karol Koltun updated CAMEL-12472:
-
Environment:
* Camel versions: 2.17.0 and 2.21.0
* Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel test
environment ftp.
* Files: depending on configuration from 1mb to 5mb file is vital for error to
happen.
was:
Tested on:
* Camel versions: 2.17.0 and 2.21.0
* Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel test
environment ftp.
* Files: depending on configuration from 1mb to 5mb file is vital for error to
happen.
> Downloading a large file with streamDownload and stepwise hangs
>
>
> Key: CAMEL-12472
> URL: https://issues.apache.org/jira/browse/CAMEL-12472
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.21.0
> Environment: * Camel versions: 2.17.0 and 2.21.0
> * Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel
> test environment ftp.
> * Files: depending on configuration from 1mb to 5mb file is vital for error
> to happen.
>Reporter: Karol Koltun
>Priority: Major
> Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
>
>
> *Downloading a file exceeding certain, system-dependent size with
> streamDownload and stepwise options turned on hangs and causes timeout.*
> I prepared a test which triggers the error. The patch file is pretty big, as
> I had to make a file enough big to make the timeout happen. Basing on my
> predictions, the size of the file triggering the error depends on FTP
> configuration and Java caching policy (no proof available yet). Working with
> plain Vsftpd server even 1mb files triggered timeouts. In the test
> environment the limit on my desktop is 5 mb. If the test passes, please make
> the file bigger.
> My intepretation of the problem:
> # Start downloading a file with size exceeding InputStream cache (on my pc
> approx. 1mb is the limit).
>
> [FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
> {code:java}
> InputStream is = this.client.retrieveFileStream(remoteName);
> {code}
> # The server responds 150 and opens data connection.
> {code:java}
> [user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
> connection for x (1048576 bytes)."
> {code}
> # The data connection does not end because InputStream is waiting for reads
> and it has not cached whole file. No "226 Transfer complete" response from
> server.
> # Try to change directory as stepwise is turned on.
>
> [FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
> {code:java}
> this.changeCurrentDirectory(currentDir);
> {code}
> # Camel hangs as the server is still in the data connection and we are
> waiting for response from CWD command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12472) Downloading a large file with streamDownload and stepwise hangs
[
https://issues.apache.org/jira/browse/CAMEL-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karol Koltun updated CAMEL-12472:
-
Summary: Downloading a large file with streamDownload and stepwise hangs
(was: Downloading a large file with streamDownload and stepwise timeOut )
> Downloading a large file with streamDownload and stepwise hangs
>
>
> Key: CAMEL-12472
> URL: https://issues.apache.org/jira/browse/CAMEL-12472
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.21.0
> Environment: Tested on:
> * Camel versions: 2.17.0 and 2.21.0
> * Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel
> test environment ftp.
> * Files: depending on configuration from 1mb to 5mb file is vital for error
> to happen.
>Reporter: Karol Koltun
>Priority: Major
> Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
>
>
> *Downloading a file exceeding certain, system-dependent size with
> streamDownload and stepwise options turned on hangs and causes timeout.*
> I prepared a test which triggers the error. The patch file is pretty big, as
> I had to make a file enough big to make the timeout happen. Basing on my
> predictions, the size of the file triggering the error depends on FTP
> configuration and Java caching policy (no proof available yet). Working with
> plain Vsftpd server even 1mb files triggered timeouts. In the test
> environment the limit on my desktop is 5 mb. If the test passes, please make
> the file bigger.
> My intepretation of the problem:
> # Start downloading a file with size exceeding InputStream cache (on my pc
> approx. 1mb is the limit).
>
> [FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
> {code:java}
> InputStream is = this.client.retrieveFileStream(remoteName);
> {code}
> # The server responds 150 and opens data connection.
> {code:java}
> [user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
> connection for x (1048576 bytes)."
> {code}
> # The data connection does not end because InputStream is waiting for reads
> and it has not cached whole file. No "226 Transfer complete" response from
> server.
> # Try to change directory as stepwise is turned on.
>
> [FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
> {code:java}
> this.changeCurrentDirectory(currentDir);
> {code}
> # Camel hangs as the server is still in the data connection and we are
> waiting for response from CWD command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12472) Downloading a large file with streamDownload and stepwise timeOut
Karol Koltun created CAMEL-12472:
Summary: Downloading a large file with streamDownload and stepwise
timeOut
Key: CAMEL-12472
URL: https://issues.apache.org/jira/browse/CAMEL-12472
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 2.21.0
Environment: Tested on:
* Camel versions: 2.17.0 and 2.21.0
* Ftp servers: plain vsftpd server, org.apache.ftpserver as a mock, Camel test
environment ftp.
* Files: depending on configuration from 1mb to 5mb file is vital for error to
happen.
Reporter: Karol Koltun
Attachments: 0001-FtpSimpleConsumeStreamingStepwiseTest.patch
*Downloading a file exceeding certain, system-dependent size with
streamDownload and stepwise options turned on hangs and causes timeout.*
I prepared a test which triggers the error. The patch file is pretty big, as I
had to make a file enough big to make the timeout happen. Basing on my
predictions, the size of the file triggering the error depends on FTP
configuration and Java caching policy (no proof available yet). Working with
plain Vsftpd server even 1mb files triggered timeouts. In the test environment
the limit on my desktop is 5 mb. If the test passes, please make the file
bigger.
My intepretation of the problem:
# Start downloading a file with size exceeding InputStream cache (on my pc
approx. 1mb is the limit).
[FtpOperations.java:373|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L423]
{code:java}
InputStream is = this.client.retrieveFileStream(remoteName);
{code}
# The server responds 150 and opens data connection.
{code:java}
[user_ftp] FTP response: Client "127.0.0.1", "150 Opening BINARY mode data
connection for x (1048576 bytes)."
{code}
# The data connection does not end because InputStream is waiting for reads
and it has not cached whole file. No "226 Transfer complete" response from
server.
# Try to change directory as stepwise is turned on.
[FtpOperations.java:387|https://github.com/apache/camel/blob/dc6caa696255240a2a27c3bf229fc3aac9014401/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L443]
{code:java}
this.changeCurrentDirectory(currentDir);
{code}
# Camel hangs as the server is still in the data connection and we are waiting
for response from CWD command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16455785#comment-16455785
]
Luca Burgazzoli edited comment on CAMEL-10793 at 4/27/18 6:07 AM:
--
I think it could work too.
The rationale behind the DSL is that I may not want to expose the full URI but
only the options that are needed to contact the service, i.e. for http based
services we don't need to expose the implementation (jetty, undertow) but only
the protocol (http/s) so I think a service component would work nice with
endpoints/consumers that implements an interface like DiscoverableService which
greatly reduce the amount of option one may need to set on the URI.
was (Author: lb):
I think it could work too.
The rationale behind the DSL is that I may not want to expose the full URI but
only the options that are needed to contact the service, i.e. for http based
services we don't need to expose the implementation (jetty, undertow) but only
the protocol (http/s) so the service component would work nice with
endpoints/consumenrs that implements an interface like DiscoverableService
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-10793) camel cloud: expose routes as a service
[
https://issues.apache.org/jira/browse/CAMEL-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16455785#comment-16455785
]
Luca Burgazzoli edited comment on CAMEL-10793 at 4/27/18 6:06 AM:
--
I think it could work too.
The rationale behind the DSL is that I may not want to expose the full URI but
only the options that are needed to contact the service, i.e. for http based
services we don't need to expose the implementation (jetty, undertow) but only
the protocol (http/s) so the service component would work nice with
endpoints/consumenrs that implements an interface like DiscoverableService
was (Author: lb):
I think it could work too.
The rationale behind the DSL is that I may not want to expose the full URI but
only the options that are needed to contact the service, i.e. for http bases
services we don't need to expose the implementation (jetty, undertow) but only
the protocol (http/s) so the service component would work nice with
endpoints/consumenrs that implements an interface like DiscoverableService
> camel cloud: expose routes as a service
> ---
>
> Key: CAMEL-10793
> URL: https://issues.apache.org/jira/browse/CAMEL-10793
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Major
> Labels: cloud
> Fix For: 2.22.0
>
>
> As today we have a ServiceCall EIP that makes it easy to call external
> services in a cloud environment leveraging external service registry such as
> kubernetes, consul, etcd, spring-cloud & co so It could make sense to add a
> way for a route to register itself in such registries and be available as a
> service for other to consume.
> Something like:
> {code:java}
> // programmatic config
> from("jetty:http://0.0.0.0:8001/service1;)
> .serviceRegistry()
> .name("service-1")
> .host("")
> .port(8001)
> .meta("camel.protocol", "http")
> .meta("camel.component", "jetty")
> .meta("camel.context.path", "/service1")
> .end()
> .to("direct:service-1")
> // Inherit from a global config and eventually override it
> from("jetty:http://0.0.0.0:8002/service2;)
> .serviceRegistry("service-2")
> .configRef("service-registry-conf")
> .port(8002)
> .to("direct:service-2")
> // Smart auto configuration
> // i.e. if the endpoint implements DiscoverableService
> from("jetty:http://0.0.0.0:8003/service3;)
> .serviceRegistry("service-3")
> .to("direct:service-3")
> {code}
> Beside making camel play better in cloud environment, you can use the
> service call to connect camel based micro services with minimal configuration
> as the registration may provide some additional meta data that the service
> call can use for auto-configuration (of course not all the registries can do
> it).
> The future Health API/Service may then also be configured to remove or
> invalidate the service if the route is reported as not healthy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
