You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by matthewm <mm...@gmail.com> on 2010/04/13 01:22:48 UTC
Injecting ProducerTemplates, scoping, and JMX memleak
Hello,
We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a web
service.
We've been using @EndpointInject to inject ProducerTemplates into our beans.
Some of our beans are request scoped, and so a new ProducerTemplate is
created and injected on each request.
After more study this seems to run counter to the idea of ProducerTemplate,
which appears to have been conceived as a long-lived object rather than
transient. It seems perhaps the documentation of @EndpointInject might
point this out; injecting into singletons makes perfect sense but injecting
into request-scoped beans may be undesirable.
Specifically, the issue we found is that each ProducerTemplate creates a
Producer which then is registered with JMX. Eventually we wind up with
thousands of Producers referenced by JMX (but otherwise garbage) resulting
in OOM errors.
It seems like a bug that Camel's JMX integration prevents producers from
being eligible for GC. But how best to proceed with making a
ProducerTemplate available to request scoped beans?
Thanks!
Matt
--
View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28219199.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by Willem Jiang <wi...@gmail.com>.
Hi Matt,
Please see my comment in the mail.
matthewm wrote:
> Thank you Claus and Willem.
>
> The plot thickened a bit this morning.
>
> Hoping that disabling JMX would disable the leak, I turned it off (by adding
> an <agent> definition to my application context). This slowed but did not
> eliminate the leak. Further digging showed that, even with management
> disabled, there is a collection in DefaultCamelContext (servicesToClose)
> that still results in retention of Producers.
Thanks for your information, please log a JIRA with the test case, so we
can keep on tracing it.
>
> Hoping to defeat the leak, I took Claus' advice and defined a named producer
> template (with <template id="XXX"/>) in the camel context definition, and
> used @Autowired to have spring inject the PT. However, I found that Spring
> was still injecting a new PT instance every time. Further investigation
> showed that org.apache.camel.spring.CamelProducerTemplateFactoryBean is, at
> least in 2.2.0, hardwired to always create "prototype" beans rather than
> singletons. i.e., its getObject() method will always return a new PT every
> time.
>
It's easy to fix. I will head to it today.
> Out of desperation I explicitly configured a DefaultProducerTemplate as a
> Spring singleton bean:
>
> <bean id="camelProducerTemplate"
> class="org.apache.camel.impl.DefaultProducerTemplate">
> <constructor-arg ref="camel"/>
> </bean>
>
> and used @Resource(name="camelProducerTemplate") to inject it by name. This
> solved the problem and reliably injected the same PT instance, but I was a
> bit unhappy about having to reference an .impl. class directly.
>
> Willem I'm not sure I understand your suggestion:
>
>> It's a good idea to inject a new ProducerTemplate per request.
Sorry , it a typo, I mean it's not a good idea.
>
> It seems instead like a very bad idea; at least in 2.2.0 any pattern which
> results in unbounded creation of ProducerTemplates will result in a
> reference leak, as best as I can tell.
>
> Please let me know if any of this should be considered a bug and I'll be
> happy to file a ticket or tickets.
>
> Thanks again for your replies.
>
> Matt
>
>
> Claus Ibsen-2 wrote:
>> On Tue, Apr 13, 2010 at 1:22 AM, matthewm <mm...@gmail.com> wrote:
>>> Hello,
>>>
>>> We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a
>>> web
>>> service.
>>>
>>> We've been using @EndpointInject to inject ProducerTemplates into our
>>> beans.
>>> Some of our beans are request scoped, and so a new ProducerTemplate is
>>> created and injected on each request.
>>>
>>> After more study this seems to run counter to the idea of
>>> ProducerTemplate,
>>> which appears to have been conceived as a long-lived object rather than
>>> transient. It seems perhaps the documentation of @EndpointInject might
>>> point this out; injecting into singletons makes perfect sense but
>>> injecting
>>> into request-scoped beans may be undesirable.
>>>
>> The FAQ has some details on producer template
>> http://camel.apache.org/why-does-camel-use-too-many-threads-with-producertemplate.html
>>
>> You can just use @Autowired or other Spring IoC stuff.
>>
>> @Autowired
>> private ProducerTemplate template;
>>
>> Camel will automatic enlist a ProducerTemplate if you do not explict
>> set a <template id="xxx"/> in the <camelContext/> tag.
>> Then it will use the shared instance of ProducerTemplate instead of
>> creating a new one each time.
>>
>>
>>> Specifically, the issue we found is that each ProducerTemplate creates a
>>> Producer which then is registered with JMX. Eventually we wind up with
>>> thousands of Producers referenced by JMX (but otherwise garbage)
>>> resulting
>>> in OOM errors.
>>>
>> Yeah this is fixed in 2.3-SNAPSHOT.
>>
>>> It seems like a bug that Camel's JMX integration prevents producers from
>>> being eligible for GC. But how best to proceed with making a
>>> ProducerTemplate available to request scoped beans?
>>>
>>> Thanks!
>>>
>>> Matt
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28219199.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Have created a ticket about this issue
https://issues.apache.org/activemq/browse/CAMEL-2650
On Thu, Apr 15, 2010 at 11:36 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Wed, Apr 14, 2010 at 3:22 AM, matthewm <mm...@gmail.com> wrote:
>>
>> Thank you Claus and Willem.
>>
>> The plot thickened a bit this morning.
>>
>> Hoping that disabling JMX would disable the leak, I turned it off (by adding
>> an <agent> definition to my application context). This slowed but did not
>> eliminate the leak. Further digging showed that, even with management
>> disabled, there is a collection in DefaultCamelContext (servicesToClose)
>> that still results in retention of Producers.
>>
>
> This is a catch-22 situation. When using @Producer or @Consume etc.
> you are creating a Producer/Consumer up front.
> However you also want to stop the @Producer / @Consumer again when you
> are shutting down, or more ideally before if the POJO was no longer in
> use.
>
> However there is no nice API for doing that, so either we could just
> omit the stop and then risk having resources leaked as they are not
> properly stopped.
>
> If you look in the CamelPostProcessorHelper in camel-core in the
> #startService method.
> Its the one which "registers" it in CamelContext (servicesToClose).
>
> We can obviously change that to not do so but just start the service
> with registering.
> But again then we loose the ability to close it.
>
> Any thoughts?
>
> We could maybe have a WeakReference or something to it. So if the ref
> still holds on shutdown we can stop it, if not, then its just bad luck
> :)
>
>
>
>
>> Hoping to defeat the leak, I took Claus' advice and defined a named producer
>> template (with <template id="XXX"/>) in the camel context definition, and
>> used @Autowired to have spring inject the PT. However, I found that Spring
>> was still injecting a new PT instance every time. Further investigation
>> showed that org.apache.camel.spring.CamelProducerTemplateFactoryBean is, at
>> least in 2.2.0, hardwired to always create "prototype" beans rather than
>> singletons. i.e., its getObject() method will always return a new PT every
>> time.
>>
>
> Yeah there is a bug in those factory bean as it should have been set
> to singleton = true.
>
>
>
>> Out of desperation I explicitly configured a DefaultProducerTemplate as a
>> Spring singleton bean:
>>
>> <bean id="camelProducerTemplate"
>> class="org.apache.camel.impl.DefaultProducerTemplate">
>> <constructor-arg ref="camel"/>
>> </bean>
>>
>> and used @Resource(name="camelProducerTemplate") to inject it by name. This
>> solved the problem and reliably injected the same PT instance, but I was a
>> bit unhappy about having to reference an .impl. class directly.
>>
>> Willem I'm not sure I understand your suggestion:
>>
>>> It's a good idea to inject a new ProducerTemplate per request.
>>
>> It seems instead like a very bad idea; at least in 2.2.0 any pattern which
>> results in unbounded creation of ProducerTemplates will result in a
>> reference leak, as best as I can tell.
>>
>> Please let me know if any of this should be considered a bug and I'll be
>> happy to file a ticket or tickets.
>>
>> Thanks again for your replies.
>>
>> Matt
>>
>>
>> Claus Ibsen-2 wrote:
>>>
>>> On Tue, Apr 13, 2010 at 1:22 AM, matthewm <mm...@gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a
>>>> web
>>>> service.
>>>>
>>>> We've been using @EndpointInject to inject ProducerTemplates into our
>>>> beans.
>>>> Some of our beans are request scoped, and so a new ProducerTemplate is
>>>> created and injected on each request.
>>>>
>>>> After more study this seems to run counter to the idea of
>>>> ProducerTemplate,
>>>> which appears to have been conceived as a long-lived object rather than
>>>> transient. It seems perhaps the documentation of @EndpointInject might
>>>> point this out; injecting into singletons makes perfect sense but
>>>> injecting
>>>> into request-scoped beans may be undesirable.
>>>>
>>>
>>> The FAQ has some details on producer template
>>> http://camel.apache.org/why-does-camel-use-too-many-threads-with-producertemplate.html
>>>
>>> You can just use @Autowired or other Spring IoC stuff.
>>>
>>> @Autowired
>>> private ProducerTemplate template;
>>>
>>> Camel will automatic enlist a ProducerTemplate if you do not explict
>>> set a <template id="xxx"/> in the <camelContext/> tag.
>>> Then it will use the shared instance of ProducerTemplate instead of
>>> creating a new one each time.
>>>
>>>
>>>> Specifically, the issue we found is that each ProducerTemplate creates a
>>>> Producer which then is registered with JMX. Eventually we wind up with
>>>> thousands of Producers referenced by JMX (but otherwise garbage)
>>>> resulting
>>>> in OOM errors.
>>>>
>>>
>>> Yeah this is fixed in 2.3-SNAPSHOT.
>>>
>>>> It seems like a bug that Camel's JMX integration prevents producers from
>>>> being eligible for GC. But how best to proceed with making a
>>>> ProducerTemplate available to request scoped beans?
>>>>
>>>> Thanks!
>>>>
>>>> Matt
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28219199.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>>
>>
>> --
>> View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28237439.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Thanks for the advise. In the mean time we have improved the original
issue with having
prototype scoped @Producer being added as services to close.
This is now fixed on trunk as Camel now detects the scope of the bean
and only for singletons will
add it as a service to close.
For prototypes a WARN log is logged once to remind you to close it yourself.
Will look into a solution to have it auto closed as well.
On Thu, Apr 15, 2010 at 8:05 PM, matthewm <mm...@gmail.com> wrote:
>
>
>
>> This is a catch-22 situation. When using @Producer or @Consume etc.
>> you are creating a Producer/Consumer up front.
>> However you also want to stop the @Producer / @Consumer again when you
>> are shutting down, or more ideally before if the POJO was no longer in
>> use.
>>
>> However there is no nice API for doing that, so either we could just
>> omit the stop and then risk having resources leaked as they are not
>> properly stopped.
>>
>> If you look in the CamelPostProcessorHelper in camel-core in the
>> #startService method.
>> Its the one which "registers" it in CamelContext (servicesToClose).
>>
>> We can obviously change that to not do so but just start the service
>> with registering.
>> But again then we loose the ability to close it.
>>
>> Any thoughts?
>>
>
> Could you leverage lifecycle callbacks in Spring?
>
> http://static.springsource.org/spring/docs/3.0.1.RELEASE/reference/html/beans.html#beans-factory-lifecycle-disposablebean
>
> If @EndpointInject or @Produce create a ProducerTemplate and PT then
> registers/starts its Producer(s) with CamelContext.addService, it seems
> appropriate that as part of the lifecycle, when the PT's containing bean is
> torn down, a destruction callback should be responsible for stopping any
> Producers associated with the PT and de-registering them with the
> CamelContext. Right now, initialization is automatic but there is no
> corresponding de-initialization being done.
>
> Though this might mean that you need a Spring-specific
> DefaultProducerTemplate subclass (or some other Spring-specific
> implementation of ProducerTemplate) that is lifecycle-aware, since DPT still
> needs to be usable without Spring.
>
> Matt
>
> --
> View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28258673.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by matthewm <mm...@gmail.com>.
> This is a catch-22 situation. When using @Producer or @Consume etc.
> you are creating a Producer/Consumer up front.
> However you also want to stop the @Producer / @Consumer again when you
> are shutting down, or more ideally before if the POJO was no longer in
> use.
>
> However there is no nice API for doing that, so either we could just
> omit the stop and then risk having resources leaked as they are not
> properly stopped.
>
> If you look in the CamelPostProcessorHelper in camel-core in the
> #startService method.
> Its the one which "registers" it in CamelContext (servicesToClose).
>
> We can obviously change that to not do so but just start the service
> with registering.
> But again then we loose the ability to close it.
>
> Any thoughts?
>
Could you leverage lifecycle callbacks in Spring?
http://static.springsource.org/spring/docs/3.0.1.RELEASE/reference/html/beans.html#beans-factory-lifecycle-disposablebean
If @EndpointInject or @Produce create a ProducerTemplate and PT then
registers/starts its Producer(s) with CamelContext.addService, it seems
appropriate that as part of the lifecycle, when the PT's containing bean is
torn down, a destruction callback should be responsible for stopping any
Producers associated with the PT and de-registering them with the
CamelContext. Right now, initialization is automatic but there is no
corresponding de-initialization being done.
Though this might mean that you need a Spring-specific
DefaultProducerTemplate subclass (or some other Spring-specific
implementation of ProducerTemplate) that is lifecycle-aware, since DPT still
needs to be usable without Spring.
Matt
--
View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28258673.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Apr 14, 2010 at 3:22 AM, matthewm <mm...@gmail.com> wrote:
>
> Thank you Claus and Willem.
>
> The plot thickened a bit this morning.
>
> Hoping that disabling JMX would disable the leak, I turned it off (by adding
> an <agent> definition to my application context). This slowed but did not
> eliminate the leak. Further digging showed that, even with management
> disabled, there is a collection in DefaultCamelContext (servicesToClose)
> that still results in retention of Producers.
>
This is a catch-22 situation. When using @Producer or @Consume etc.
you are creating a Producer/Consumer up front.
However you also want to stop the @Producer / @Consumer again when you
are shutting down, or more ideally before if the POJO was no longer in
use.
However there is no nice API for doing that, so either we could just
omit the stop and then risk having resources leaked as they are not
properly stopped.
If you look in the CamelPostProcessorHelper in camel-core in the
#startService method.
Its the one which "registers" it in CamelContext (servicesToClose).
We can obviously change that to not do so but just start the service
with registering.
But again then we loose the ability to close it.
Any thoughts?
We could maybe have a WeakReference or something to it. So if the ref
still holds on shutdown we can stop it, if not, then its just bad luck
:)
> Hoping to defeat the leak, I took Claus' advice and defined a named producer
> template (with <template id="XXX"/>) in the camel context definition, and
> used @Autowired to have spring inject the PT. However, I found that Spring
> was still injecting a new PT instance every time. Further investigation
> showed that org.apache.camel.spring.CamelProducerTemplateFactoryBean is, at
> least in 2.2.0, hardwired to always create "prototype" beans rather than
> singletons. i.e., its getObject() method will always return a new PT every
> time.
>
Yeah there is a bug in those factory bean as it should have been set
to singleton = true.
> Out of desperation I explicitly configured a DefaultProducerTemplate as a
> Spring singleton bean:
>
> <bean id="camelProducerTemplate"
> class="org.apache.camel.impl.DefaultProducerTemplate">
> <constructor-arg ref="camel"/>
> </bean>
>
> and used @Resource(name="camelProducerTemplate") to inject it by name. This
> solved the problem and reliably injected the same PT instance, but I was a
> bit unhappy about having to reference an .impl. class directly.
>
> Willem I'm not sure I understand your suggestion:
>
>> It's a good idea to inject a new ProducerTemplate per request.
>
> It seems instead like a very bad idea; at least in 2.2.0 any pattern which
> results in unbounded creation of ProducerTemplates will result in a
> reference leak, as best as I can tell.
>
> Please let me know if any of this should be considered a bug and I'll be
> happy to file a ticket or tickets.
>
> Thanks again for your replies.
>
> Matt
>
>
> Claus Ibsen-2 wrote:
>>
>> On Tue, Apr 13, 2010 at 1:22 AM, matthewm <mm...@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a
>>> web
>>> service.
>>>
>>> We've been using @EndpointInject to inject ProducerTemplates into our
>>> beans.
>>> Some of our beans are request scoped, and so a new ProducerTemplate is
>>> created and injected on each request.
>>>
>>> After more study this seems to run counter to the idea of
>>> ProducerTemplate,
>>> which appears to have been conceived as a long-lived object rather than
>>> transient. It seems perhaps the documentation of @EndpointInject might
>>> point this out; injecting into singletons makes perfect sense but
>>> injecting
>>> into request-scoped beans may be undesirable.
>>>
>>
>> The FAQ has some details on producer template
>> http://camel.apache.org/why-does-camel-use-too-many-threads-with-producertemplate.html
>>
>> You can just use @Autowired or other Spring IoC stuff.
>>
>> @Autowired
>> private ProducerTemplate template;
>>
>> Camel will automatic enlist a ProducerTemplate if you do not explict
>> set a <template id="xxx"/> in the <camelContext/> tag.
>> Then it will use the shared instance of ProducerTemplate instead of
>> creating a new one each time.
>>
>>
>>> Specifically, the issue we found is that each ProducerTemplate creates a
>>> Producer which then is registered with JMX. Eventually we wind up with
>>> thousands of Producers referenced by JMX (but otherwise garbage)
>>> resulting
>>> in OOM errors.
>>>
>>
>> Yeah this is fixed in 2.3-SNAPSHOT.
>>
>>> It seems like a bug that Camel's JMX integration prevents producers from
>>> being eligible for GC. But how best to proceed with making a
>>> ProducerTemplate available to request scoped beans?
>>>
>>> Thanks!
>>>
>>> Matt
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28219199.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28237439.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by matthewm <mm...@gmail.com>.
Thank you Claus and Willem.
The plot thickened a bit this morning.
Hoping that disabling JMX would disable the leak, I turned it off (by adding
an <agent> definition to my application context). This slowed but did not
eliminate the leak. Further digging showed that, even with management
disabled, there is a collection in DefaultCamelContext (servicesToClose)
that still results in retention of Producers.
Hoping to defeat the leak, I took Claus' advice and defined a named producer
template (with <template id="XXX"/>) in the camel context definition, and
used @Autowired to have spring inject the PT. However, I found that Spring
was still injecting a new PT instance every time. Further investigation
showed that org.apache.camel.spring.CamelProducerTemplateFactoryBean is, at
least in 2.2.0, hardwired to always create "prototype" beans rather than
singletons. i.e., its getObject() method will always return a new PT every
time.
Out of desperation I explicitly configured a DefaultProducerTemplate as a
Spring singleton bean:
<bean id="camelProducerTemplate"
class="org.apache.camel.impl.DefaultProducerTemplate">
<constructor-arg ref="camel"/>
</bean>
and used @Resource(name="camelProducerTemplate") to inject it by name. This
solved the problem and reliably injected the same PT instance, but I was a
bit unhappy about having to reference an .impl. class directly.
Willem I'm not sure I understand your suggestion:
> It's a good idea to inject a new ProducerTemplate per request.
It seems instead like a very bad idea; at least in 2.2.0 any pattern which
results in unbounded creation of ProducerTemplates will result in a
reference leak, as best as I can tell.
Please let me know if any of this should be considered a bug and I'll be
happy to file a ticket or tickets.
Thanks again for your replies.
Matt
Claus Ibsen-2 wrote:
>
> On Tue, Apr 13, 2010 at 1:22 AM, matthewm <mm...@gmail.com> wrote:
>>
>> Hello,
>>
>> We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a
>> web
>> service.
>>
>> We've been using @EndpointInject to inject ProducerTemplates into our
>> beans.
>> Some of our beans are request scoped, and so a new ProducerTemplate is
>> created and injected on each request.
>>
>> After more study this seems to run counter to the idea of
>> ProducerTemplate,
>> which appears to have been conceived as a long-lived object rather than
>> transient. It seems perhaps the documentation of @EndpointInject might
>> point this out; injecting into singletons makes perfect sense but
>> injecting
>> into request-scoped beans may be undesirable.
>>
>
> The FAQ has some details on producer template
> http://camel.apache.org/why-does-camel-use-too-many-threads-with-producertemplate.html
>
> You can just use @Autowired or other Spring IoC stuff.
>
> @Autowired
> private ProducerTemplate template;
>
> Camel will automatic enlist a ProducerTemplate if you do not explict
> set a <template id="xxx"/> in the <camelContext/> tag.
> Then it will use the shared instance of ProducerTemplate instead of
> creating a new one each time.
>
>
>> Specifically, the issue we found is that each ProducerTemplate creates a
>> Producer which then is registered with JMX. Eventually we wind up with
>> thousands of Producers referenced by JMX (but otherwise garbage)
>> resulting
>> in OOM errors.
>>
>
> Yeah this is fixed in 2.3-SNAPSHOT.
>
>> It seems like a bug that Camel's JMX integration prevents producers from
>> being eligible for GC. But how best to proceed with making a
>> ProducerTemplate available to request scoped beans?
>>
>> Thanks!
>>
>> Matt
>> --
>> View this message in context:
>> http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28219199.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28237439.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Apr 13, 2010 at 1:22 AM, matthewm <mm...@gmail.com> wrote:
>
> Hello,
>
> We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a web
> service.
>
> We've been using @EndpointInject to inject ProducerTemplates into our beans.
> Some of our beans are request scoped, and so a new ProducerTemplate is
> created and injected on each request.
>
> After more study this seems to run counter to the idea of ProducerTemplate,
> which appears to have been conceived as a long-lived object rather than
> transient. It seems perhaps the documentation of @EndpointInject might
> point this out; injecting into singletons makes perfect sense but injecting
> into request-scoped beans may be undesirable.
>
The FAQ has some details on producer template
http://camel.apache.org/why-does-camel-use-too-many-threads-with-producertemplate.html
You can just use @Autowired or other Spring IoC stuff.
@Autowired
private ProducerTemplate template;
Camel will automatic enlist a ProducerTemplate if you do not explict
set a <template id="xxx"/> in the <camelContext/> tag.
Then it will use the shared instance of ProducerTemplate instead of
creating a new one each time.
> Specifically, the issue we found is that each ProducerTemplate creates a
> Producer which then is registered with JMX. Eventually we wind up with
> thousands of Producers referenced by JMX (but otherwise garbage) resulting
> in OOM errors.
>
Yeah this is fixed in 2.3-SNAPSHOT.
> It seems like a bug that Camel's JMX integration prevents producers from
> being eligible for GC. But how best to proceed with making a
> ProducerTemplate available to request scoped beans?
>
> Thanks!
>
> Matt
> --
> View this message in context: http://old.nabble.com/Injecting-ProducerTemplates%2C-scoping%2C-and-JMX-memleak-tp28219199p28219199.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Injecting ProducerTemplates, scoping, and JMX memleak
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
ProducerTemplates has a cache which holds the reference of the endpoints
those he send to. It's a good idea to inject a new ProducerTemplate
per request. We need to update the document for it.
The JMX issue should be fixed also, please feel free to log a JIRA[1]
for it.
[1]https://issues.apache.org/activemq/browse/CAMEL
Willem
matthewm wrote:
> Hello,
>
> We are using Camel 2.2.0 with Spring 3.0.1.RELEASE in the context of a web
> service.
>
> We've been using @EndpointInject to inject ProducerTemplates into our beans.
> Some of our beans are request scoped, and so a new ProducerTemplate is
> created and injected on each request.
>
> After more study this seems to run counter to the idea of ProducerTemplate,
> which appears to have been conceived as a long-lived object rather than
> transient. It seems perhaps the documentation of @EndpointInject might
> point this out; injecting into singletons makes perfect sense but injecting
> into request-scoped beans may be undesirable.
>
> Specifically, the issue we found is that each ProducerTemplate creates a
> Producer which then is registered with JMX. Eventually we wind up with
> thousands of Producers referenced by JMX (but otherwise garbage) resulting
> in OOM errors.
>
> It seems like a bug that Camel's JMX integration prevents producers from
> being eligible for GC. But how best to proceed with making a
> ProducerTemplate available to request scoped beans?
>
> Thanks!
>
> Matt