You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by niteshjain <ni...@gmail.com> on 2016/09/09 03:50:20 UTC
Re: ProducerTemplate creates too much threads
Hi,
Can you please look into this query:
http://camel.465427.n5.nabble.com/Should-i-start-stop-producer-templates-often-td5787400.html
any help is appreciated.
Thanks,
Nithesh
--
View this message in context: http://camel.465427.n5.nabble.com/ProducerTemplate-creates-too-much-threads-tp5751299p5787401.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: ProducerTemplate creates too much threads
Posted by Brad Johnson <br...@mediadriver.com>.
It's extremely important to learn the EIPs available to you in Camel and
leverage them to the greatest extent possible. They'll do a lot of the
heavy lifting. You can use a CBR to send data to various routes or beans
based on some value in the data header or body, for example.
I handle SOAP requests all the time without using Processors. As an
example of how this is easily accomplished look at this snippet of
blueprint. It could be done in others as well.
<recipientList>
<simple>direct-vm:${header.operationName}</simple>
</recipientList>
The operation name there is set on the method of the SOAP interface or in
the WSDL (though I usually go code first.)
If you set up routes that are based on the operation name listening on that
then they will receive the message. So here's a definition of an API and
I've decorated it for use in both the SOAP and REST endpoints. (The REST
endpoints/uris in @Path are named incorrectly here as they should be noun
based but it gets the idea across.)
@WebMethod(operationName = "getFoo", action = "")
@GET
@Path("/resource/bar/{token}")
@Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@Consumes({MediaType.APPLICATION_JSON,MediaType.APPLICATION_JSON})
public String getFoo(@WebParam Foo foo);
@WebMethod(operationName = "addFoo", action = "")
@PUT
@Path("/resource/foo/{token}")
@Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@Consumes({MediaType.APPLICATION_JSON,MediaType.APPLICATION_JSON})
public void addFoo(@WebParam Foo foo);
So we have this in our SOAP and REST related camel contexts/routes.
<recipientList>
<simple>direct-vm:${header.operationName}</simple>
</recipientList>
<camelContext id="Foo-SOAP-context" xmlns="
http://camel.apache.org/schema/blueprint">
<route id="Foo-SOAP">
<from uri="cxf:bean:fooSOAPEndpoint" />
<transform>
<simple>${body[0]}</simple>
</transform>
<recipientList>
<simple>direct-vm:${header.operationName}</simple>
</recipientList>
</route>
</camelContext>
In the same or different bundle you can then add:
<route id="fooAddRoute">
<from uri="direct-vm:addFoo">
<bean ref="fooAddHandler"/>
<to ...whoever is next or if nothing, then return something from
the handler or if the SOAP/REST endpoint is void return nothing.
</route>
Now whether the request is coming in through SOAP or REST it is will invoke
the addFoo route, unmarshal the object into a Foo object, and send it to
the route.
No need to use Processors, ProducerTemplates or anything else. Just let
Camel do the work for you and learn the EIPs!
On Sun, Sep 11, 2016 at 12:19 AM, niteshjain <ni...@gmail.com>
wrote:
> I'm using Processor interface, to handle the incoming SOAP request from the
> Exchange and apply some business logic on it, Based on the business logic I
> wanted to invoke different camel routes (defined in camel context xml),
> hence ProducerTemplate to invoke different camel routes.
>
> Regards,
> Nithesh
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/ProducerTemplate-creates-too-much-threads-tp5751299p5787445.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: ProducerTemplate creates too much threads
Posted by niteshjain <ni...@gmail.com>.
I'm using Processor interface, to handle the incoming SOAP request from the
Exchange and apply some business logic on it, Based on the business logic I
wanted to invoke different camel routes (defined in camel context xml),
hence ProducerTemplate to invoke different camel routes.
Regards,
Nithesh
--
View this message in context: http://camel.465427.n5.nabble.com/ProducerTemplate-creates-too-much-threads-tp5751299p5787445.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: ProducerTemplate creates too much threads
Posted by Brad Johnson <br...@mediadriver.com>.
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 <ni...@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.
>
Re: ProducerTemplate creates too much threads
Posted by niteshjain <ni...@gmail.com>.
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.
Re: ProducerTemplate creates too much threads
Posted by Brad Johnson <br...@mediadriver.com>.
OK, but that doesn't apply to an inject ProducerTemplate in a bean, only to
ones created on the incoming thread.
If you have something like. It is an *instance *variable. It is not created
on the incoming thread but is only created at start up time.
public class FooHandler {
@EndpointInject(uri="activemq:foo.bar")
ProducerTemplate producer;
public void doSomething() {
if (whatever) {
producer.sendBody("<hello>world!</hello>");
}
}
http://camel.apache.org/pojo-producing.html
Make sure you look at what they are conveying. This not suggesting that
you create a singleton and serve up ProducerTemplates from it. It is
saying you shouldn't create them inside the invocation (on the incoming
thread). Specifically it says: *You are not meant to create a
ProducerTemplate for each message invocation; you are meant to create a
single instance on startup and keep it around.*
http://camel.apache.org/why-does-camel-use-too-many-threads-with-producertemplate.html
On Thu, Sep 8, 2016 at 10:50 PM, niteshjain <ni...@gmail.com> wrote:
> Hi,
>
> Can you please look into this query:
> http://camel.465427.n5.nabble.com/Should-i-start-stop-
> producer-templates-often-td5787400.html
>
> any help is appreciated.
>
> Thanks,
> Nithesh
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/ProducerTemplate-creates-too-much-threads-tp5751299p5787401.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>