This was indeed a good and proper leak, introduced by changes made since 0.12. I have made an update to fix the leak, if you rerun your test now it should work better.
Robbie On 29 October 2011 03:46, Praveen M <[email protected]> wrote: > Thanks a lot Robbie for the prompt reply and looking into this. > > Praveen > > On Fri, Oct 28, 2011 at 7:41 PM, Robbie Gemmell > <[email protected]>wrote: > >> This isn't a current known issue since work was previously undertaken >> to fix similar problems, so this sounds like a new bug or possibly >> something that has been reintroduced. The Method[] objects are part of >> the underlying transport layer backing each JMS Session, so they will >> directly correlate to the number of Connections and Sessions you are >> creating, although there appear to have been exactly twice what you >> indicated you are using per run which is stange. They should be >> getting cleared up, but something is obviously holding onto them. >> >> Opening and closing a connection and session per message is of course >> rather inefficient, but it should of course still work. I'll add this >> to my list of things to look at. >> >> Robbie >> >> On 28 October 2011 20:01, Praveen M <[email protected]> wrote: >> > Hi, >> > >> > I ran the following test a few times and I ran into a OOM exception. Can >> > someone please tell me if i'm doing something wrong or if this could >> > potentially be a bug? Thanks. >> > >> > 1) Create 1000 queues. >> > 2) Create 4 consumers -> each consumer uses it's own connection >> > 3) In a loop do the following, >> > >> > for each queues 1..1000 { >> > create producer(create new connection) for queue |i| >> > produce 1 message for that queue. >> > close producer (close connection) >> > } >> > >> > 4) Wait till all messages are consumed by the 4 consumers and then close >> all >> > 4 consumers. >> > 5) Re-Run the test without a broker restart >> > >> > Each time the test ran, it created and closed 1004 connections (with at >> most >> > 5 connections living in parallel...we close the earlier queue's >> producer's >> > connection before creating a producer for the next queue). >> > >> > Also, I checked for any stray threads on the client side due to any >> unclosed >> > connection, and it looks like everything was closed fine (I didn't see >> any >> > stray threads). >> > >> > On the broker side, I saw that the memory usage creeps up each time i >> re-run >> > the test, and eventually hits a OOM. (Running the above test about 5 >> times >> > causes a OOM ) >> > >> > I tried profiling the broker to see what's holding on to all that memory >> and >> > saw a certain class's(org.apache.qpid.transport.Method[]) instance count >> > grow up each time my test was run and it was holding the maximum memory >> in >> > the broker. >> > >> > The number of instances of org.apache.qpid.transport.Method[] were >> trending >> > as follows: >> > >> > After first test - 2008 >> > After second test - 4016 >> > ... and so on. >> > >> > There seems to be a direct relation between the number of those objects >> and >> > the connections created and closed. ~ Why are these objects not freed on >> > closing the connection?? >> > I'm using the Java Broker out of trunk and using it with a >> DerbyMessageStore >> > for the test. >> > >> > Or is there something fundamentally wrong by the way I run the test, I >> guess >> > opening and closing so many connections isn't a great idea (maybe I >> should >> > be dealing with sessions). But still, I see that this can be a potential >> > problem in a really long running broker system(where we cannot afford to >> > restart the broker periodically) which can have clients joining/leaving >> at >> > regular intervals. >> > >> > >> > Thank you for all the effort answering our questions, >> > -- >> > -Praveen >> > >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > > > -- > -Praveen > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
