geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: ActiveMQ and other runtime memory leaks identified by DayTrader
Date Tue, 15 Nov 2005 23:41:11 GMT
Hi Aaron,
You're referring to http://issues.apache.org/jira/browse/GERONIMO-1165

I get the same behavior that you documented. I think David is correct -- I
don't see how this could be an ActiveMQ issue. ActiveMQ has a task to clean
up expired messages from their message store. Their default is to cleanup
expired messages every 5 minutes. That all seems quite reasonable.

Changing the pool size back to 100 (I kept the blocking timout and idle
timeout the same) makes the problem go away. By implication, this means an
idle server uses 65 connections? Well, I tried 66 and that gets a failure.
80 doesn't get the failure. I spared myself a binary search for precision...

Is this really a <problem>? It does seem like a lot of connections. I'll
poke around, but this doesn't seem like a very high-priority issue.

Does highlight the need for some statistics on pool utilization, etc (I
recall Matt mentioning that...)

--kevan

On 11/15/05, Aaron Mulder < ammulder@alumni.princeton.edu> wrote:
>
> I also noticed that if you turn down the system database pool size
> from 100 to 65, ActiveMQ starts to complain about not being able to
> get a connection (and that's with no JMS activity!). It may be worth
> a little investigation, though David J though it might be a problem in
> the pooling code not ActiveMQ. I think I created a JIRA for this.
>
> Aaron
>
> On 11/15/05, Kevan Miller < kevan.miller@gmail.com> wrote:
> > I posted to the ActiveMQ dev list last week (I see that Dain did, also)
> > regarding
> > http://issues.apache.org/jira/browse/GERONIMO-1155. I
> > haven't had a response, yet.
> >
> > I did a little more digging through a HEAPDUMP that was generated at the
>
> > time of the OutOfMemoryException. It shows that there were over 150,000
> > ActiveMQSession objects. By my calculations they were responsible for
> over
> > 300 megs of a 512 meg heap.
> >
> > Since there was quite a bit of memory left-over, I looked for more
> likely
> > culprits. I see a large number of objects being held by the DB2 driver.
> I'm
> > working on resolving these...
> >
> > Quite possible that there are other problems. However, the
> signal-to-noise
> > ration is pretty low. I'm going to wait for progress on the above issues
>
> > before exploring further...
> >
> > --kevan
> >
>

Mime
View raw message