RE: Cannot acquire read lock within x millis
I should add that I'm seeing the "Cannot acquire read lock within x millis" messages appear in the logs of both application servers several seconds apart, implying that the two instances are not polling at precisely the same time. Yet neither of them are able to process the file for several rounds of polling before one of them does. Thanks, Mark From: Mark Harris Sent: 18 March 2020 13:55 To: users@camel.apache.org Subject: Cannot acquire read lock within x millis Hello, I'm encountering the following message in my logs when two instances of a Java application running Camel on separate servers (to ensure HA) are trying to poll an sFTP server to process a file: Cannot acquire read lock within 2 millis. Will skip the file: RemoteFile[name and path of file on sFTP server] The route URI is like this: sftp://@:/?connectTimeout=12=60s=true=true=truechanged=10s=30 The process copies the file to a local shared folder where it is further processed by routes running on the same 2 Java applications with a URI like this: file://?delay=60s===changed=10s ... where I also get the same message: Cannot acquire read lock within 1 millis. Will skip the file: GenericFile[name and path of file on shared folder] Eventually the file is processed but it is taking several polls before one of the applications processes the file, leading to delays. Can anyone advise what the issue is and how I can fix it, please? I'm using Camel v 2.24.2. Thanks, Mark
Cannot acquire read lock within x millis
Hello, I'm encountering the following message in my logs when two instances of a Java application running Camel on separate servers (to ensure HA) are trying to poll an sFTP server to process a file: Cannot acquire read lock within 2 millis. Will skip the file: RemoteFile[name and path of file on sFTP server] The route URI is like this: sftp://@:/?connectTimeout=12=60s=true=true=truechanged=10s=30 The process copies the file to a local shared folder where it is further processed by routes running on the same 2 Java applications with a URI like this: file://?delay=60s===changed=10s ... where I also get the same message: Cannot acquire read lock within 1 millis. Will skip the file: GenericFile[name and path of file on shared folder] Eventually the file is processed but it is taking several polls before one of the applications processes the file, leading to delays. Can anyone advise what the issue is and how I can fix it, please? I'm using Camel v 2.24.2. Thanks, Mark
Re: Some questions on CamelK
Thanks for your time, looking forward for the in depth CamelK webinar! Op di 17 mrt. 2020 om 14:11 schreef Claus Ibsen : > On Tue, Mar 17, 2020 at 12:06 PM ski n wrote: > > > > Yes, it's clear how Kubernetes/Camel K is used. I just speak from the > field > > which mostly goes like this: > > > > 1) IT strategy is to move (everything) to the cloud > > 2) Engineers propose Kubernetes > > 3) The integration specialists propose CamelK > > 4) The architect propose an "event-driven architecture" > > > > Everyone is enthusiastic, first integration will be some event-driven > thing > > between microservices. Success! However everyone wants after that > > everything works in this one solution. So in practice everyone wants to > > reuse non-cloud protocols and patterns. I already see their next request: > > > > Ah yeah that is a great observation. > The IT world is not shiny greenfield with only latest and greatest > shiny cloud systems, and protocols. > > > > > "Please get files from our Windows file share and send an email based on > > the file" > > > > Yeah you can move a lot of data via files ;) > > So knative has sources which you can plugin, but of course its mainly > a few cloud protocols so far, and kafka. > But Camel K can bridge to that with all its 200+ components. But you > need to setup that via knative yaml and also > transform the data to cloud events. So its not super easy plug and > play. But it has potential. > > > > From a theoretical perspective it easy to say no, but in practice...Also, > > to fulfill real business case (event typical cloud use cases) a lot of > > complexity needs to be added. In practice no one understands the > > limitations. Maybe I would be good that on the Camel page there will be > > more explanation on the use cases and limitations of CamelK. Also which > > Camel components works good with CamelK and which not. > > > > All the components work with Camel K (well all the ones you can run > standalone, so skip osgi, servlet and a few others). > It all just runs on a JVM. > > > > As a side note: > > > > You spoke of no code/low code solution. When I think of low-code I would > > think more of Fuse Online/Syndesis then CamelK. Here it is more of less > > code/DSL/convention-over-configuration type of thing, but at the end it's > > still code. > > > > Yeah syndesis is targeting this, but possible mostly the no-code and > non developer space, with its web UI driven "glue together systems" > style. > > > > > > > > > > > > > > > > Op di 17 mrt. 2020 om 09:23 schreef Claus Ibsen : > > > > > Camel K is not for a traditional Java development project with many > > > dependencies and source code files, and complex builds and so on. > > > Its for low-code/no-code lightweight integration in the cloud (= > > > kubernetes) for users whom may not be hard-core Java developers. > > > > > > For traditional java development projects then look at camel-quarkus > > > or still use spring boot (but SB is heavy for Java in containers) for > > > cloud workloads (= kubernetes). > > > That becomes just a standard container image with a JVM base that you > run. > > > > > > Camel K runs via "intelligence" via the Camel K operator that "figures > > > out how to run your stuff". > > > > > > With Camel K its still 100% Camel and you have CamelContext and all of > > > that. But it focused on hiding that more, and just make the route DSL > > > front and center, where you do "low code" to specify what to integrate > > > together. > > > > > > > > > > > > > > > > > > On Tue, Mar 17, 2020 at 9:13 AM ski n > wrote: > > > > > > > > Ad 1) Dependency resolution > > > > > > > > As I understand it. > > > > > > > > a) The user doesn't need to to specify Camel dependencies, but other > > > > dependency (like i.e. Guava) needs to be explicitly defined > > > > b) If it's a Camel dependency then CamelK will map the scheme to the > > > maven > > > > artifact > > > > c) The Camel and all other artifacts are then downloaded from maven > > > central > > > > if needed and compiled (or injected at runtime?) > > > > > > > > Seems like a very useful feature for other implementations like Camel > > > > Standalone, Wildfly/EAP, Spring boot, Karaf as well. > > > > > > > > Ad 2) Running multiple files > > > > > > > > Would be nice to specify just a root directory and Kamel will scans > this > > > > directory recursively. > > > > > > > > Ad 3) Interacting with CamelK > > > > > > > > So the option is either to use "Kamel CLI" or for Java use the > > > > kubernetes-java client that has java api for k8s. > > > > > > > > OK, thanks. Wished to stay within the Camel Framework as much as > > > possible. > > > > My estimation is: > > > > > > > > Option 1) Easy to use Kamel, but hard hard to combine this with > > > > traditional Camel apps ( Camel Standalone, Wildfly/EAP, Spring boot, > > > Karaf) > > > > Option 2) Hard to use K8's API (need to write a CamelK client > wrapper), > > > > but easy to combine with traditional Camel. > > > > >
Re: Some questions on CamelK
On Tue, Mar 17, 2020 at 12:06 PM ski n wrote: > > Yes, it's clear how Kubernetes/Camel K is used. I just speak from the field > which mostly goes like this: > > 1) IT strategy is to move (everything) to the cloud > 2) Engineers propose Kubernetes > 3) The integration specialists propose CamelK > 4) The architect propose an "event-driven architecture" > > Everyone is enthusiastic, first integration will be some event-driven thing > between microservices. Success! However everyone wants after that > everything works in this one solution. So in practice everyone wants to > reuse non-cloud protocols and patterns. I already see their next request: > Ah yeah that is a great observation. The IT world is not shiny greenfield with only latest and greatest shiny cloud systems, and protocols. > "Please get files from our Windows file share and send an email based on > the file" > Yeah you can move a lot of data via files ;) So knative has sources which you can plugin, but of course its mainly a few cloud protocols so far, and kafka. But Camel K can bridge to that with all its 200+ components. But you need to setup that via knative yaml and also transform the data to cloud events. So its not super easy plug and play. But it has potential. > From a theoretical perspective it easy to say no, but in practice...Also, > to fulfill real business case (event typical cloud use cases) a lot of > complexity needs to be added. In practice no one understands the > limitations. Maybe I would be good that on the Camel page there will be > more explanation on the use cases and limitations of CamelK. Also which > Camel components works good with CamelK and which not. > All the components work with Camel K (well all the ones you can run standalone, so skip osgi, servlet and a few others). It all just runs on a JVM. > As a side note: > > You spoke of no code/low code solution. When I think of low-code I would > think more of Fuse Online/Syndesis then CamelK. Here it is more of less > code/DSL/convention-over-configuration type of thing, but at the end it's > still code. > Yeah syndesis is targeting this, but possible mostly the no-code and non developer space, with its web UI driven "glue together systems" style. > > > > > > > Op di 17 mrt. 2020 om 09:23 schreef Claus Ibsen : > > > Camel K is not for a traditional Java development project with many > > dependencies and source code files, and complex builds and so on. > > Its for low-code/no-code lightweight integration in the cloud (= > > kubernetes) for users whom may not be hard-core Java developers. > > > > For traditional java development projects then look at camel-quarkus > > or still use spring boot (but SB is heavy for Java in containers) for > > cloud workloads (= kubernetes). > > That becomes just a standard container image with a JVM base that you run. > > > > Camel K runs via "intelligence" via the Camel K operator that "figures > > out how to run your stuff". > > > > With Camel K its still 100% Camel and you have CamelContext and all of > > that. But it focused on hiding that more, and just make the route DSL > > front and center, where you do "low code" to specify what to integrate > > together. > > > > > > > > > > > > On Tue, Mar 17, 2020 at 9:13 AM ski n wrote: > > > > > > Ad 1) Dependency resolution > > > > > > As I understand it. > > > > > > a) The user doesn't need to to specify Camel dependencies, but other > > > dependency (like i.e. Guava) needs to be explicitly defined > > > b) If it's a Camel dependency then CamelK will map the scheme to the > > maven > > > artifact > > > c) The Camel and all other artifacts are then downloaded from maven > > central > > > if needed and compiled (or injected at runtime?) > > > > > > Seems like a very useful feature for other implementations like Camel > > > Standalone, Wildfly/EAP, Spring boot, Karaf as well. > > > > > > Ad 2) Running multiple files > > > > > > Would be nice to specify just a root directory and Kamel will scans this > > > directory recursively. > > > > > > Ad 3) Interacting with CamelK > > > > > > So the option is either to use "Kamel CLI" or for Java use the > > > kubernetes-java client that has java api for k8s. > > > > > > OK, thanks. Wished to stay within the Camel Framework as much as > > possible. > > > My estimation is: > > > > > > Option 1) Easy to use Kamel, but hard hard to combine this with > > > traditional Camel apps ( Camel Standalone, Wildfly/EAP, Spring boot, > > Karaf) > > > Option 2) Hard to use K8's API (need to write a CamelK client wrapper), > > > but easy to combine with traditional Camel. > > > > > > My question comes from that there is already a lot of Camel > > implementations > > > out there. It's already a big step to go from for example Wildfly to > > Spring > > > Boot, but to Kubernetes seems to be a bigger hurdle. > > > > > > For example now I have a Spring boot Camel application. Everything > > > Registry, Route, Processors works perfectly. Say one company wants
Re: Some questions on CamelK
Yes, it's clear how Kubernetes/Camel K is used. I just speak from the field which mostly goes like this: 1) IT strategy is to move (everything) to the cloud 2) Engineers propose Kubernetes 3) The integration specialists propose CamelK 4) The architect propose an "event-driven architecture" Everyone is enthusiastic, first integration will be some event-driven thing between microservices. Success! However everyone wants after that everything works in this one solution. So in practice everyone wants to reuse non-cloud protocols and patterns. I already see their next request: "Please get files from our Windows file share and send an email based on the file" >From a theoretical perspective it easy to say no, but in practice...Also, to fulfill real business case (event typical cloud use cases) a lot of complexity needs to be added. In practice no one understands the limitations. Maybe I would be good that on the Camel page there will be more explanation on the use cases and limitations of CamelK. Also which Camel components works good with CamelK and which not. As a side note: You spoke of no code/low code solution. When I think of low-code I would think more of Fuse Online/Syndesis then CamelK. Here it is more of less code/DSL/convention-over-configuration type of thing, but at the end it's still code. Op di 17 mrt. 2020 om 09:23 schreef Claus Ibsen : > Camel K is not for a traditional Java development project with many > dependencies and source code files, and complex builds and so on. > Its for low-code/no-code lightweight integration in the cloud (= > kubernetes) for users whom may not be hard-core Java developers. > > For traditional java development projects then look at camel-quarkus > or still use spring boot (but SB is heavy for Java in containers) for > cloud workloads (= kubernetes). > That becomes just a standard container image with a JVM base that you run. > > Camel K runs via "intelligence" via the Camel K operator that "figures > out how to run your stuff". > > With Camel K its still 100% Camel and you have CamelContext and all of > that. But it focused on hiding that more, and just make the route DSL > front and center, where you do "low code" to specify what to integrate > together. > > > > > > On Tue, Mar 17, 2020 at 9:13 AM ski n wrote: > > > > Ad 1) Dependency resolution > > > > As I understand it. > > > > a) The user doesn't need to to specify Camel dependencies, but other > > dependency (like i.e. Guava) needs to be explicitly defined > > b) If it's a Camel dependency then CamelK will map the scheme to the > maven > > artifact > > c) The Camel and all other artifacts are then downloaded from maven > central > > if needed and compiled (or injected at runtime?) > > > > Seems like a very useful feature for other implementations like Camel > > Standalone, Wildfly/EAP, Spring boot, Karaf as well. > > > > Ad 2) Running multiple files > > > > Would be nice to specify just a root directory and Kamel will scans this > > directory recursively. > > > > Ad 3) Interacting with CamelK > > > > So the option is either to use "Kamel CLI" or for Java use the > > kubernetes-java client that has java api for k8s. > > > > OK, thanks. Wished to stay within the Camel Framework as much as > possible. > > My estimation is: > > > > Option 1) Easy to use Kamel, but hard hard to combine this with > > traditional Camel apps ( Camel Standalone, Wildfly/EAP, Spring boot, > Karaf) > > Option 2) Hard to use K8's API (need to write a CamelK client wrapper), > > but easy to combine with traditional Camel. > > > > My question comes from that there is already a lot of Camel > implementations > > out there. It's already a big step to go from for example Wildfly to > Spring > > Boot, but to Kubernetes seems to be a bigger hurdle. > > > > For example now I have a Spring boot Camel application. Everything > > Registry, Route, Processors works perfectly. Say one company wants to use > > this application on a traditional VM and a second company want to use the > > same application in OpenShift. When I move that application to Kubernetes > > can I move the workload from my Spring boot application running in > > Openshift to KNative/CamelK and still manage it from my > CamelContext/Spring > > Boot? Or do I need two code bases then? > > > > As you mentioned before companies have all kind of different > > workloads/protocols. The nice things about Camel I can all be > > configured/managed this form one place/framework. Seems like I need to > > rewrite/migrate the event based routes first to the CamelK way of > working. > > > > So my main point is that while you may ideally switch to an event > > based/microservice world where you run locally and in the cloud > everything > > on Kubernetes or Openshift. However if both worlds needs to be supported > > then you stand with one leg in one world and with your other leg in the > > other. Moving back and forward. Looking for reuse and reconcile both > worlds > > a little :)
Re: How to prevent the logging of patient identifiers
You can also investigate writing your own log4j / logback filter / appender
to filter out log statements that may contain sensitive information.
Le mar. 17 mars 2020 à 11:07, Claus Ibsen a écrit :
> Hi
>
> You can configure the error handler logging level, incl / excl stracktraces
> etc.
> Or you can do a custom onException and then handle the exception, and then
> do your own logging etc.
>
>
>
> On Tue, Mar 17, 2020 at 10:44 AM Paw B Sørensen
> wrote:
>
> > Hi,
> >
> >
> >
> > I am using the camel fhir component to retrieve observations for a
> > patient. As part of the request I set the URL including query params
> > identifying the patient:
> >
> >
> >
> > .setHeader(FhirConstants.PROPERTY_PREFIX + "url",
> > constant("Observation?subject:Patient=091234"))
> >
> > .toD(String.format("fhir:%s/%s",
> >
> >
> >
> FhirApiCollection.getCollection().getApiName(FhirSearchApiMethod.class).getName(),
> >
> > FhirSearchApiMethod.SEARCHBYURL.getName()) +
> >
> > "?encoding=XML" +
> >
> > "=false" +
> >
> > "=NEVER")
> >
> >
> >
> > If the request fails for example HTTP 404 Not Found because the patient
> > was unknown then the resulting RuntimeCamelException logged by the
> > RedeliveryErrorHandler includes the URL.
> >
> > This is a problem because of GDPR we cannot allow a patient identifier in
> > the log files.
> >
> > Is there any way to prevent the logging or to remove the URL before the
> > logging
> >
> >
> >
> >
> >
> > Paw B Sørensen
> >
> > paw.b.soren...@systematic.com
> >
> >
> >
> > Med venlig hilsen / Kind regards
> >
> > [image: Systematic Logo]
Re: How to prevent the logging of patient identifiers
Hi
You can configure the error handler logging level, incl / excl stracktraces
etc.
Or you can do a custom onException and then handle the exception, and then
do your own logging etc.
On Tue, Mar 17, 2020 at 10:44 AM Paw B Sørensen
wrote:
> Hi,
>
>
>
> I am using the camel fhir component to retrieve observations for a
> patient. As part of the request I set the URL including query params
> identifying the patient:
>
>
>
> .setHeader(FhirConstants.PROPERTY_PREFIX + "url",
> constant("Observation?subject:Patient=091234"))
>
> .toD(String.format("fhir:%s/%s",
>
>
> FhirApiCollection.getCollection().getApiName(FhirSearchApiMethod.class).getName(),
>
> FhirSearchApiMethod.SEARCHBYURL.getName()) +
>
> "?encoding=XML" +
>
> "=false" +
>
> "=NEVER")
>
>
>
> If the request fails for example HTTP 404 Not Found because the patient
> was unknown then the resulting RuntimeCamelException logged by the
> RedeliveryErrorHandler includes the URL.
>
> This is a problem because of GDPR we cannot allow a patient identifier in
> the log files.
>
> Is there any way to prevent the logging or to remove the URL before the
> logging
>
>
>
>
>
> Paw B Sørensen
>
> paw.b.soren...@systematic.com
>
>
>
> Med venlig hilsen / Kind regards
>
> [image: Systematic Logo]
How to prevent the logging of patient identifiers
Hi,
I am using the camel fhir component to retrieve observations for a patient. As
part of the request I set the URL including query params identifying the
patient:
.setHeader(FhirConstants.PROPERTY_PREFIX + "url",
constant("Observation?subject:Patient=091234"))
.toD(String.format("fhir:%s/%s",
FhirApiCollection.getCollection().getApiName(FhirSearchApiMethod.class).getName(),
FhirSearchApiMethod.SEARCHBYURL.getName()) +
"?encoding=XML" +
"=false" +
"=NEVER")
If the request fails for example HTTP 404 Not Found because the patient was
unknown then the resulting RuntimeCamelException logged by the
RedeliveryErrorHandler includes the URL.
This is a problem because of GDPR we cannot allow a patient identifier in the
log files.
Is there any way to prevent the logging or to remove the URL before the logging
Paw B Sørensen
paw.b.soren...@systematic.com
Med venlig hilsen / Kind regards
[Systematic Logo]
www.systematic.com
Re: Some questions on CamelK
Camel K is not for a traditional Java development project with many dependencies and source code files, and complex builds and so on. Its for low-code/no-code lightweight integration in the cloud (= kubernetes) for users whom may not be hard-core Java developers. For traditional java development projects then look at camel-quarkus or still use spring boot (but SB is heavy for Java in containers) for cloud workloads (= kubernetes). That becomes just a standard container image with a JVM base that you run. Camel K runs via "intelligence" via the Camel K operator that "figures out how to run your stuff". With Camel K its still 100% Camel and you have CamelContext and all of that. But it focused on hiding that more, and just make the route DSL front and center, where you do "low code" to specify what to integrate together. On Tue, Mar 17, 2020 at 9:13 AM ski n wrote: > > Ad 1) Dependency resolution > > As I understand it. > > a) The user doesn't need to to specify Camel dependencies, but other > dependency (like i.e. Guava) needs to be explicitly defined > b) If it's a Camel dependency then CamelK will map the scheme to the maven > artifact > c) The Camel and all other artifacts are then downloaded from maven central > if needed and compiled (or injected at runtime?) > > Seems like a very useful feature for other implementations like Camel > Standalone, Wildfly/EAP, Spring boot, Karaf as well. > > Ad 2) Running multiple files > > Would be nice to specify just a root directory and Kamel will scans this > directory recursively. > > Ad 3) Interacting with CamelK > > So the option is either to use "Kamel CLI" or for Java use the > kubernetes-java client that has java api for k8s. > > OK, thanks. Wished to stay within the Camel Framework as much as possible. > My estimation is: > > Option 1) Easy to use Kamel, but hard hard to combine this with > traditional Camel apps ( Camel Standalone, Wildfly/EAP, Spring boot, Karaf) > Option 2) Hard to use K8's API (need to write a CamelK client wrapper), > but easy to combine with traditional Camel. > > My question comes from that there is already a lot of Camel implementations > out there. It's already a big step to go from for example Wildfly to Spring > Boot, but to Kubernetes seems to be a bigger hurdle. > > For example now I have a Spring boot Camel application. Everything > Registry, Route, Processors works perfectly. Say one company wants to use > this application on a traditional VM and a second company want to use the > same application in OpenShift. When I move that application to Kubernetes > can I move the workload from my Spring boot application running in > Openshift to KNative/CamelK and still manage it from my CamelContext/Spring > Boot? Or do I need two code bases then? > > As you mentioned before companies have all kind of different > workloads/protocols. The nice things about Camel I can all be > configured/managed this form one place/framework. Seems like I need to > rewrite/migrate the event based routes first to the CamelK way of working. > > So my main point is that while you may ideally switch to an event > based/microservice world where you run locally and in the cloud everything > on Kubernetes or Openshift. However if both worlds needs to be supported > then you stand with one leg in one world and with your other leg in the > other. Moving back and forward. Looking for reuse and reconcile both worlds > a little :) > > > Kind regards, > > Raymond > > > > Op ma 16 mrt. 2020 om 19:48 schreef Claus Ibsen : > > > Hi > > > > Its a bunch of questions I will give a few points with the limited time I > > have. > > > > We want to do a webinar in the future about Camel K with more deep > > dive, especially around its 1.0 GA release timeframe. > > > > Ad 1) > > You can read about dependency resolution here > > https://camel.apache.org/camel-k/latest/configuration/dependencies.html > > > > Camel K uses the camel-catalog to know how to map from component names > > to maven artifacts. > > https://github.com/apache/camel/tree/master/catalog/camel-catalog > > > > > > Ad 2) > > You can specify multiple files from the CLI > > > > kamel run File1.java File2.java > > > > Being able to run with *.java or something is AFAIK not currently > > supported, but we are open for ideas. > > > > Ad 3) > > Camel K uses standard Kubernetes CRD (custom resource definitions). > > So any tool/language that can talk to the k8s API server (rest calls) > > you can use. > > And of course also the kubernetes client - kubectl. > > > > For Java there is the kubernetes-java client that has java api for k8s. > > > > Ad 4) > > Scaling is not Camel K specific. You can setup replicas and quotes and > > limits etc which are standard k8s concepts. > > But for scaling then Knative is the interesting add-on for k8s that > > event based scaling. Camel K works with that too. > > > > However knative is likely more for modern cloud workloads, and not for > > traditional enterprise systems
Re: Some questions on CamelK
Ad 1) Dependency resolution
As I understand it.
a) The user doesn't need to to specify Camel dependencies, but other
dependency (like i.e. Guava) needs to be explicitly defined
b) If it's a Camel dependency then CamelK will map the scheme to the maven
artifact
c) The Camel and all other artifacts are then downloaded from maven central
if needed and compiled (or injected at runtime?)
Seems like a very useful feature for other implementations like Camel
Standalone, Wildfly/EAP, Spring boot, Karaf as well.
Ad 2) Running multiple files
Would be nice to specify just a root directory and Kamel will scans this
directory recursively.
Ad 3) Interacting with CamelK
So the option is either to use "Kamel CLI" or for Java use the
kubernetes-java client that has java api for k8s.
OK, thanks. Wished to stay within the Camel Framework as much as possible.
My estimation is:
Option 1) Easy to use Kamel, but hard hard to combine this with
traditional Camel apps ( Camel Standalone, Wildfly/EAP, Spring boot, Karaf)
Option 2) Hard to use K8's API (need to write a CamelK client wrapper),
but easy to combine with traditional Camel.
My question comes from that there is already a lot of Camel implementations
out there. It's already a big step to go from for example Wildfly to Spring
Boot, but to Kubernetes seems to be a bigger hurdle.
For example now I have a Spring boot Camel application. Everything
Registry, Route, Processors works perfectly. Say one company wants to use
this application on a traditional VM and a second company want to use the
same application in OpenShift. When I move that application to Kubernetes
can I move the workload from my Spring boot application running in
Openshift to KNative/CamelK and still manage it from my CamelContext/Spring
Boot? Or do I need two code bases then?
As you mentioned before companies have all kind of different
workloads/protocols. The nice things about Camel I can all be
configured/managed this form one place/framework. Seems like I need to
rewrite/migrate the event based routes first to the CamelK way of working.
So my main point is that while you may ideally switch to an event
based/microservice world where you run locally and in the cloud everything
on Kubernetes or Openshift. However if both worlds needs to be supported
then you stand with one leg in one world and with your other leg in the
other. Moving back and forward. Looking for reuse and reconcile both worlds
a little :)
Kind regards,
Raymond
Op ma 16 mrt. 2020 om 19:48 schreef Claus Ibsen :
> Hi
>
> Its a bunch of questions I will give a few points with the limited time I
> have.
>
> We want to do a webinar in the future about Camel K with more deep
> dive, especially around its 1.0 GA release timeframe.
>
> Ad 1)
> You can read about dependency resolution here
> https://camel.apache.org/camel-k/latest/configuration/dependencies.html
>
> Camel K uses the camel-catalog to know how to map from component names
> to maven artifacts.
> https://github.com/apache/camel/tree/master/catalog/camel-catalog
>
>
> Ad 2)
> You can specify multiple files from the CLI
>
> kamel run File1.java File2.java
>
> Being able to run with *.java or something is AFAIK not currently
> supported, but we are open for ideas.
>
> Ad 3)
> Camel K uses standard Kubernetes CRD (custom resource definitions).
> So any tool/language that can talk to the k8s API server (rest calls)
> you can use.
> And of course also the kubernetes client - kubectl.
>
> For Java there is the kubernetes-java client that has java api for k8s.
>
> Ad 4)
> Scaling is not Camel K specific. You can setup replicas and quotes and
> limits etc which are standard k8s concepts.
> But for scaling then Knative is the interesting add-on for k8s that
> event based scaling. Camel K works with that too.
>
> However knative is likely more for modern cloud workloads, and not for
> traditional enterprise systems like JMS messaging, or FTP data
> transfers.
> But Camel can bridge that world and allow Camel components to act as
> sink and sources for knative eventing.
>
> For k8s concepts then I also recommend the k8s patterns book by Bilgin
> and Roland.
> https://k8spatterns.io/
>
>
>
>
> On Mon, Mar 16, 2020 at 6:42 PM ski n wrote:
> >
> > Hi all,
> >
> > In the last presentation there was also a short demo on CamelK. That
> looked
> > very interesting, but I have some questions on how does it work,
> especially
> > in more complex use cases.
> >
> > Here are some questions I have:
> >
> > Question 1: Dependency resolution
> >
> > In CamelK you can provide the following:
> >
> > from("imap://ad...@myserver.com")
> > .to("seda:output")
> >
> > Because imap is not part of core this will start the dependency
> resolution.
> > How does this work? How does CamelK know it needs the mail component as
> > dependency? Is there some kind of fixed mapping between the scheme and
> > component?
> >
> > Say for example I have the following route:
> >
> > from("seda:input")
> >
