Guys, FYI: After some investigation, I think that this issue JIRA issue SMXCOMP-24. Replacing the async reply with a sync reply appears to fix the leak, although I think that is an other leak within activeMQ or within the handling of activeMQ. The memory usage graphs appear to show an increase (although significantly slower - so it may not be a leak!). The classes witha a large number of instances are:
java.util.HashMap$Entry org.apache.activemq.command.ConsumerId org.apache.activemq.command.SessionId org.apache.activemq.command.ConnectionId Stuart. -----Original Message----- From: Stuart Roe [mailto:[email protected]] Sent: 24 November 2009 11:28 To: [email protected] Subject: RE: Not deallocating resources causing Old Gen memory leaks Gert, Thanks for the reply. I have taken your advise and used jmap's histo option to collect information on the number of instances of objects. I ran a test lastnight and have taken numerous histograms (jmap -histo) this morning and have identified (I think) a memory leak in the handling of message exchange. The histograms were created by hitting the GC button in jconsole and running the jmap command straight afterwards (trying to reduce the noise from other normal create->use->destroy operations). The following list shows the number of instances for 6 samples followed by the name of the class. Unfortunately, the period between the samples has not been consistent, so it's not possible to calculte a leak rate. There is a lot of noise on the java.lang.String class, but all the other classes show a consistent increase in the number of instances and there is a large number of servicemix/jbi/messaging related classes mentioned. >From this, I conclude that there is: A). a memory leak within the SMX 3.3.1/eip 2009.01/bean 2009.01. B). my code is missing a close/release/dispose function call releasing the resources. Could I encounter a problem if the createExchangeFactory() function was called every time a message was received? Should the returned factory be cached for reuse? Stuart. -> Process runtime increasing -> 26849 30911 39184 45096 52555 64386 java.util.HashMap$Entry 23261 32837 44761 28405 34285 29189 java.lang.String 10754 12122 15144 17748 20526 25229 java.util.HashMap 10745 12156 15194 17690 20460 25090 [Ljava.util.HashMap$Entry; 12327 14564 16157 16252 18389 22281 [I 7268 8042 10048 12098 14030 17384 org.apache.servicemix.jbi.messaging.InOutImpl 7268 8042 10048 12098 14030 17384 org.apache.servicemix.jbi.messaging.NormalizedMessageImpl 7272 8047 10054 12100 14032 17381 org.apache.servicemix.jbi.jaxp.StringSource 3636 4022 5024 6053 7019 8698 org.apache.servicemix.bean.support.Request 3634 4021 5024 6049 7015 8692 org.apache.servicemix.jbi.messaging.MessageExchangeFactoryImpl$PrettyCalenda r 3634 4021 5024 6049 7015 8692 sun.util.calendar.Gregorian$Date 3634 4021 5024 6049 7015 8692 org.apache.servicemix.jbi.messaging.ExchangePacket 3634 4024 5026 6046 7011 8685 java.util.HashMap$EntrySet 3667 4098 5113 6030 6972 8578 [Z 3624 4067 5080 5975 6890 8439 java.util.concurrent.ConcurrentHashMap$HashEntry 3535 4005 5027 5875 6802 8352 java.util.HashSet -----Original Message----- From: Gert Vanthienen [mailto:[email protected]] Sent: 23 November 2009 09:30 To: [email protected] Subject: Re: Not deallocating resources causing Old Gen memory leaks L.S., I'm not seeing anything obvious missing from this snippet of code. Have you tried taking a memory dump and use jmap or yourkit or something to find the objects that are causing the memore leak? Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/11/20 Stuart Roe <[email protected]>: > Hi all, > > I appear to have a memory leak while performing an exchange and I'm > unsure how to identify it/correct it. Bascially, my application > happily runs for a few days and then fails with an out of memory > exception. Using jconsole I can see that the memory usage is bouncing > around with a slow consistent creap up. This is why I suspect a memory leak. > > The message path within the app is cxf-bc (ver. 2009.01) -> cxf-se (ver. > 2009.01) all running in SMX 3.3.1/WinXP. > > The handler in CXF-SE creates a new InOut message and sync. posts it > to the NMR, unmarshals the response into a reply. There is a copy of > the handler function below. I have removed the actual data handling > and exceptions. > > My question is, I'm I missing some form of deallocation/close call > that will return/release an object and hence remove my memory leak? > I have found that replacing the message exchange from the handler and > hard wiring a response fixes the leak. > > Any help/pointers would be helpful. > > Stuart. > > BTW: > I'm using JiBX to marshal between NMR XML and Java objects (which may > also be the source of the problem). > > > public List<TypeConfigStatus> getConfigStatus() > try { > GetConfigStatusResponse response = null; > > DeliveryChannel ch = getContext().getDeliveryChannel(); > InOut exch = ch.createExchangeFactory().createInOutExchange(); > exch.setService(getService()); > exch.setInMessage(exch.createMessage()); > exch.getInMessage().setProperty("operation", "config-status"); > exch.getInMessage().setContent(new StringSource("<empty />")); > > if(ch.sendSync(exch)){ > NormalizedMessage amsg = exch.getOutMessage(); > try { > SourceTransformer trans = new SourceTransformer(); > String content = trans.contentToString(amsg); > IBindingFactory bfact = > BindingDirectory.getFactory(GetConfigStatusResponse.class); > IUnmarshallingContext uctx = > bfact.createUnmarshallingContext(); > response = (GetConfigStatusResponse) > uctx.unmarshalDocument(new StringReader(content)); > > } catch > // block removed > }finally{ > exch.setStatus(ExchangeStatus.DONE); > ch.send(exch); > } > } > > // set result = cooked(response) > > return result; > } > >
