If you can figure out how to reproduce the JMX exception in a JUnit test case we can fix it.
With regards memory consumption; you are saying RAM usage grows as you produce messages. This makes sense since we tend to cache messages around so that they are in RAM when consumers start consuming them. For non-pesistent messaging all messages stay in RAM. So firstly are you using persistent messaging? (i.e. what is the delivery mode on the producer). Secondly the journal caches messages and acks around in RAM until a checkpoint to JDBC occurs (for persistent messaging) - so you should see RAM use go down after you've sent a bunch of persistent messags, then some time later the checkpoint happens. On 6/16/06, jsalvo <[EMAIL PROTECTED]> wrote:
After restarting the broker and starting the test client, I was not able to reproduce the problem until after some significant amount of time. I believe that the reason is not because of the number of connections ... The problem is also not related to consumers ( even with consumers not cleanup cleanly ). Instead, the problem seems to be with producers. After running a JMS client producer with produced lots of messages ( non-transacted, auto-acknowledged ), JConsole shows the memory heap usage DOES NOT go down, even after telling JConsole to do a garbage collection. However, after running a JMS client consumer, JConsole shows the memory heap usage DOES go down after telling JConsole to do a garbage collection ... even if the JMS client producer did not clean up properly (e.g. testing how resilient the JMS provider is when a JMS client JVM is killed, etc.. ) I ran this test a couple of times, and the evidence so far shows that the broker is somehow not releasing some resource that the JMS client producer had even after the JMS client has exited / disconnected. Apart from that, even when there are no JMS clients, the memory usage goes up continuously ... but on slightly. Then again, even after I tell JConsole to do a GC, the heap memory usage graph does not go down as well ... So that maybe another case separate from the producer case. -- View this message in context: http://www.nabble.com/4.0-Consumer-OutOfMemoryError-bug--t1707655.html#a4895366 Sent from the ActiveMQ - User forum at Nabble.com.
-- James ------- http://radio.weblogs.com/0112098/
