Yo, tested this too. Works really well, the memory leak has disappeared. :)
On Sun, Oct 30, 2011 at 12:03 PM, Praveen M <[email protected]> wrote: > Great . Thanks a ton. I'll check on this too tomorrow and keep you posted. > > > On Sun, Oct 30, 2011 at 11:55 AM, Robbie Gemmell <[email protected] > > wrote: > >> 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] >> >> > > > -- > -Praveen > -- -Praveen
