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 <[email protected]> wrote: > 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 > -- 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
