On Wed, Apr 14, 2010 at 3:22 AM, matthewm <[email protected]> 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 <[email protected]> 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
