camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Johnson <brad.john...@mediadriver.com>
Subject Re: ProducerTemplate creates too much threads
Date Sat, 10 Sep 2016 22:33:26 GMT
Normally you don't want to shut it down until the application is shutting
down. And then it should happen of its own accord.

Another question is why are you using the Processor interface?  Unless
there's a compelling reason just use a regular old Java bean. In a lot of
these cases you don't even need a producer template.  Just let Camel do the
work. One of the biggest mistakes I see when folks start using Camel is
they'll get some input and then write an application inside a Processor.

Camel will us reflection on your bean to figure out which method to
invoke.  It will invoked the method using the body in the Exchange so you
don't have to fool with it.  You can explicitly invoke a method on a bean
if necessary (when there are two methods that take the same datatype for
example) because in that case Camel has no way of differentiating which
method you'd like to invoke.  In a number of those cases I'll just split my
handler in two and use each in its rightful place. So if your payload is
MyPayloadBean, the a MyPayloadHandler might look like this:

public class MyPayloadHandler {

public MyPaylaodBean handle(MyPayloadBean payload)
{
   //Do something withe payload here and then just return it so Camel can
route it to the next place.
   return payload;
//In reality I don't believe you even have  to return the payload if all
you are doing is mutating data on it. It will continue being used but if
you instantiate or create a new one or a different type then you'll want to
specify the return.  I do // it anyway just to make it clear as to what is
happening there so if someone else or even I have to come back later and
change it is obvious as to what is happening.
}
 I rarely if ever use Processors and the only time I'd really think about
it is if I had to muck about with headers.  Even then I'd prefer to do it
from the Camel route if I can (and 90% of the time I can). Or if I just
need access to the information they contain and don't need to mutate it
I'll add another parameter to the method and then add @Header to tell Camel
what it is I want.

http://camel.apache.org/bean-binding.html

There's a very important point to note about all this.  Notice that your
MyPayloadHandler is not dependent on the Camel framework mechanisms. It is
decoupled and is totally portable.  It also means that you can use Plain
ol' JUnit to test the MyPayloadHandler because it is just a POJO.

In the case where you are invoking a ProducerTemplate there ins't anything
particularly wrong or bad about it but ask yourself if you couldn't just
add a .to(xxxx).  In your case, I don't know what comes before the
Processor but let's say it is a file or direct or seda or whatever.

from("direct:foo").(MyPayloadHandler.class).to("direct:invokeWS");

--You can also separately instantiate the payload handler or just
instantiate it and reference it by a name.

Notice how you are letting Camel do its job here and aren't manually having
to manipulate anything.  Are there times to use Producer or Consumer
templates?  Sure, but make sure you really need them and can't just wire in
a camel route to send it on. And really think hard if you need to a use a
Processor and can't figure out another less messy way of going about it.
If you don't have a compelling reason to use the Processor then just use
Pojo.  If you don't have a compelling reason to use the ProducerTemplate,
then just use the routes.

If you look in the Camel in Action book you'll see a section in there where
Clause talks about the difference in using bean binding versus Processor.
If I had my beat up old copy around I'd tell you what page to look on.
Unfortunately so much of the online documentation shows processors being
use that that sort of gets lost.  I assume that much of that is due to its
having been written earlier before the bean binding became robust.

If I could find my beat up old copy around here I'd tell you exactly where
to look but I'm not sure where it's at.  I've been waiting to throw money
at Claus when the new copy comes out or even review it while it is in
edit.  Santa Claus has promised sometime around Christmas or so.  I hope so
because my children have already put it on their lists.

Brad


On Sat, Sep 10, 2016 at 1:24 AM, niteshjain <niteshjain132@gmail.com> wrote:

> Thanks for your valuable response,
>
> Now I'm using ProducerTemplate to invoke a camel route by injecting the
> template as below:
>
> public class Test implements Processor {
>     @EndpointInject(uri="direct:invokeWS")
>      ProducerTemplate producer;
>
>    @Override
>     public void process(Exchange exchange) throws Exception {
>       .....
>       .....
>        producer.requestBody(somePayload); //invokes the camel route
> "direct:invokeWS" as expected.
>       .....
>       .....
>     }
> }
>
> and It's working fine, my doubt is when do i call *producer.stop() method*
> to close down all the resources it has been using ?
>
> as my application will be running forever ! and for each SOAP request
> process() method of Test class will be invoked.
>
> Thanks,
> Nithesh
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/ProducerTemplate-creates-too-much-threads-tp5751299p5787436.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message