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 <mmo...@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
