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
