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 <lefthandma...@gmail.com> 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:users-subscr...@qpid.apache.org
