Can anyone tell me the difference between end() and endChoice() in camel? Can we use end() in place of endChoice()?
The endChoice() has quite an unfortunate naming. It doesn't end the choice() block, it just ends the current when() clause.
end() on the other hand closes the current choice() block.
Can also be seen in the javadocs:
endChoice
end
end() will take care end of any type of camel Component, whereas endChoice() is specific to end the the choice Component.
Related
I haven't found any useful explanation about when to use end() and endChoice() ? Also endChoice() is meant for what type of camel nodes (I am aware of only loadBalance) ?
After using recipientList in a camel route, within a choice.when, I would like to route this further to another destination with to("xy").
Syntax-highlighting in a java IDE is showing me that this is not possible.
If I put an end after recipientList, all appears to fit again.
Is that required? I could not find any examples in the docs/net showing s/t similar...
.choice()
.when(aPredicate)
.setHeader(Exchange.FILE_NAME).simple("st")
.recipientList(getAValueBuilder())
.end()
.to("ftp:me#ftpserv//usr/dest")
.when(anotherPredicate)
.to(nirv)
.setHeader(Exchange.FILE_NAME).simple("nt")
.to("ftp:me#ftpserv//usr/anotherdest")
.end()
Generarilly I am not sure, while using choice, when to use end. And to make it more difficult, there is an endChoice...
I tryed to use the formatting, to show the way I think it should be use above.
Thanks for feedback.
If X is false I want to route to A, if X is true I want to route to A and B
I tried to write something like
from(?)
.choice()
.when( X )
.multicast().to(A,B).end()
.otherwise() // I get a (compile) error underlined here saying 'otherwise() is not on type ProcessorDefinition
.to( A )
it doesn't like it
I suspect this isn't the best way of phrasing this
basically I always want to route to (A) and if that condition is there I also want to route to (B)
what is the best way of expressing this in Camel?
use endChoice() at the end of your when() clause and it'll work...
see http://camel.apache.org/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.html
See this FAQ about the choice: https://camel.apache.org/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.html
You can also use dynamic recipient list and compute the endpoints to route to. Then you can return 1 or 2 depending on the conditions: http://camel.apache.org/recipient-list.html
If you always want your message to go to route A, then do not include it in the choice clause
from(?)
.to( A )
.choice()
.when( X )
to(B).end()
Something like above should suffice your case. Also read the articles that Claus has given in his answer.
Regarding your compilation error, remove the end() after the when clause. end() causes the choice() clause to be finished but you then use otherwise() clause while choice has already been closed.
I have found that expressing your routes using the XML notation is a lot more concise in meaning.
For instance with the Java DSL people often make the mistake of not calling, or even adding 'endChoice()' and 'end()' like you have in your example; Sometimes you will also face an issue with Camel's Route Builder which is currently a limitation due to Java's Generics.
Unfortunately using XML comes with the cost of using XML :)
It might be a silly question, but say I have a hughe message that I want to process with Camel. How will the number of steps in my route affect the memory usage? Does camel deep copy my message payload for every step in the route, even if the DSL-step only reads from the message or does it do something smart here?
Is it better to keep the route down and do things in a "hughe" bean for large messages or not?
This is an example route that does various things, but not changing the payload.
from("foo:bar")
.log(..)
.setProperty(..)
.setHeader(..)
.log(..)
.choice()
.when(simple(... ) )
.log(..)
.to(..)
.when(simple(..))
.log(..)
.to(..)
.end()
from my understanding, for a simple pipelined route like this, an Exchange is created containing the body once and passed along each step in the route. Other EIPs do cause the Exchange to be copied though (like multicast, wiretap, etc)...
as well, if you have steps along the route which interface with external resources which could result in any type of copy/clone/conversion/serialization of the body unnecessarily, then you might use something like the claim check pattern to reduce this.
The camel exchange is the same through the route the message objects are copied or recereated in the steps. The body is just referenced though. So normally you should not have a problem.
This is handled by each camel processor individually though. So some of the processors may copy the body. Typically this is the case when the processor really works on the body. So in this case it can not be avoided.
The DirectComponent documentation gives the following example:
from("activemq:queue:order.in")
.to("bean:orderServer?method=validate")
.to("direct:processOrder");
from("direct:processOrder")
.to("bean:orderService?method=process")
.to("activemq:queue:order.out");
Is there any difference between that and the following?
from("activemq:queue:order.in")
.to("bean:orderServer?method=validate")
.to("bean:orderService?method=process")
.to("activemq:queue:order.out");
I've tried to find documentation on what the behaviour of the to() method is on the Java DSL, but beyond the RouteDefinition javadoc (which gives the very curt "Sends the exchange to the given endpoint") I've come up blank :(
In the very case above, you will not notice much difference. The "direct" component is much like a method call.
Once you start build a bit more complex routes, you will want to segment them in several different parts for multiple reasons.
You can, for instance, create "sub routes" that could be reused among multiple routes in your Camel context. Much like you segment out methods in regular programming to allow reusability and make code more clear. The same goes for sub routes using, for instance the direct component.
The same approach can be extended. Say you want multiple protocols to be used as endpoints to your route. You can use the direct endpoint to create the main route, something like this:
// Three endpoints to one "main" route.
from("activemq:queue:order.in")
.to("direct:processOrder");
from("file:some/file/path")
.to("direct:processOrder");
from("jetty:http://0.0.0.0/order/in")
.to("direct:processOrder");
from("direct:processOrder")
.to("bean:orderService?method=process")
.to("activemq:queue:order.out");
Another thing is that one route is created for each "from()" clause in DSL. A route is an artifact in Camel, and you could do certain administrative tasks towards it with the Camel API, such as start, stop, add, remove routes dynamically. The "to" clause is just an endpoint call.
Once starting to do some real cases with somewhat complexity in Camel, you will note that you cannot get too many "direct" routes.
Direct Component is used to name the logical segment of the route. This is similar process to naming procedures in structural programming.
In your example there is no difference in message flow. In the terms of structural programming, we could say that you make a kind of inline expansion to your route.
Another difference is Direct component doesn't has any thread pool, the direct consumer process method is invoked by the calling thread of direct producer.
Mainly its used for break the complex route configuration like in java we used to have method for reusability. And also by configuring threads at direct route we can reduce the work for calling thread .
from(A).to(B).to(OUT)
is chaining
A --- B --- OUT
But
from(A ).to( X)
from(B ).to( X)
from( X).to( OUT )
where X is a direct:?
is basically like a join
A
\____ OUT
/
B
obviously these are different behaviours, and with the second you could implement anylogic you wanted, not just a serial chain