Hi,
I currently have a similar problem which occurs from time to time and which is really a big problem: With a producer throwing out rather large messages 1MB<x <2MB every second the broker has hiccups from time to time where the memory percent usage indicator zooms through the roof causing the JVM to fill up and putting subsequently the broker into a 'braindead' situation. The only way to solve this is a restart. Deleting the responsible topic (inflight count is very large) isn't enough. Enabling spooling to disk didn't help at all as well. For some reason this is happily ignored and the temporary disk space stays '0'. I'm on this issue already for a while without success. Even worse is the fact that I can't reproduce it. Usually the messages are deleted - this has been proven. But for some bizarre reason from a certain time onwards it fills up the memory. I'll instrument a developed brokerplugin/brokerfilter to get more information to see what is happing I hope it is that complicated as I described. If it it just a little true/false configuration issue I hang myself. Cheers, Felix walec51 wrote: > > Thank for your reply > > fehm wrote: >> >> 1. Unless you have switched message persistency off, messages are always >> stored before distribution to subscribers. If you have disabled spooling >> messages to disk, it's very likely to fill up the Broker memory. >> >> 1. <lastImageSubscriptionRecoveryPolicy/> works only for retroactive >> subscriptions, means that only if your clients have 'retroactive=true' >> enabled they will see -independent of when a message has been sent- >> always the last one. Again ,this means that the server will store the >> message until a new one comes in. Do have a large number of topics ? >> >> 2. Of course a memory leak can always happen due to a bug in the server. >> However, before you should check that your clients "behave well". Make >> sure that they don't have resource leaks (e.g. not closing >> subscription/connection objects). Unfortunately, I once ran into this and >> banged my head against the wall for a while. >> Watch the subscription stats (inflight count is a good indicator, that >> the client makes problems). I recommend to use the jconsole to check >> these numbers. >> How many topics do you use/create. Remember that if the server will >> always keep your topic, hence using memory. In my experience, with 50K >> topics you need > 1024M JVM size for sure. >> > > 1. I switched the persistency off and jest I have a large number of topic. > They are created dynamically and the inactive ones are deleted from time > to time. The problem is that the memory usage doesn't seam to decrease > then they get deleted. > > 2. Thanks to the clue ! I'll look in to this. > > PS. Shouldn't the server just delete the messages in the topic if it has > not durable consumers and all the normal consumers have disconnected ? > > ----- Felix Ehm, www.cern.ch -- View this message in context: http://old.nabble.com/What-does-the-topic-size-attribute-actually-mean---tp26676103p26677960.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
