I've been looking into a memory leak we're experiencing with our Camel application and have found that the culprit seems to be com.sun.jmx.interceptor.DefaultMBeanServerInterceptor. Using MAT & taking heap dumps at the start and end of an 8 day period I can see that the memory consumption for DefaultMBeanServerInterceptor has gone from 115mb to 541mb. If I drill down further I can see that the number of objects accumulated by DefaultMBeanServerInterceptor has increased from 4,403 to 14,385. Of the managed resource objects being held by DefaultMBeanServerInterceptor, their were 703 instances of org.apache.camel.management.mbean.ManagedThreadPool at the beginning of the 8 day period, and 10,657 by the end. So the majority of 14,385 objects being held by DefaultMBeanServerInterceptor were ManagedThreadPool.
We are running Camel version 2.8.3. The application is a messaging (SMS & email) gateway connecting to multiple SMSCs and dozens of clients. It has approx 340 routes and uses ActiveMQ. We make extensive use of JMX to connect and query for memory usage, routes and ActiveMQ queues every minute or so from a separate monitoring application. Is there any knows memory issues with JMX being enabled in Camel, specifically with ManagedThreadPool? -- View this message in context: http://camel.465427.n5.nabble.com/Memory-leak-with-Camel-JMX-DefaultMBeanServerInterceptor-tp5714271.html Sent from the Camel - Users mailing list archive at Nabble.com.
