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 <
[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
>
