On 7/6/06, Kuppe <[EMAIL PROTECTED]> wrote:
James, thanks for the positive feedback. Firstly, i think the question as to which queue is actually filling up is really the one that is confusing me the most. From your reply below it seems that you are suggesting that it is the registration/deregistration queue that is full. I was expecting in fact that it would have been the "subscription queue" buffer for the client - if there is one - inside the broker.
I don't think so; given the prefetch and slow consumer settings you are using it shouldn't be the topic dispatching thats exhausting RAM
It is only on the topic that there is really high volumes of messages that could even hit the 300 mark which is being reported... Secondly, i have no concern whatsoever to use persistent messages for the registration/deregistration. The question is whether this is where the limit is reached... Q1: how can i determine which queue is actually filling up?
Use JMX and watch 'em grow? http://incubator.apache.org/activemq/jmx.html
How many queues are there - one per topic, one per subcriber per topic, one per client connection?
There are no queues by default - its your JMS client which creates them by sending messages to them, so you'd have to look at your JMS client - I've no idea.
Q2: how do i configure the RAM UsageManager? What values should I use to configure the RAM UsageManager?
Try 100Mb or so of RAM? Details of how to set the usage manager here... http://www.activemq.org/site/xml-configuration.html BTW there is every chance that it is in fact the non-durable topics are using up most of the available RAM buffer for caching messages & just a lousy error message is talking about a queue being full :)
Should this simply be calculated as bytesPerMessage * prefetchLimit * (pendingMessageLimitMultiplier + 1) * numberOfClients? How exacltly does the UsageManager actually work?
If we're talking queues, so its basically just the amount of RAM that can be used up by messages. So bytesPerMessage * maximumQueueSize roughly. But for topics it'd be something like that (though the chances are that one message is shared by many consumers)
Q3: do you confirm that i should definitely NOT be using persistent messages for the market data updates?
Non-persistent topics work great for things like market data, so I'd recommend using non-persistent topics.
How well with this scale?
Very well.
Must i allocate huge amounts of memory to the broker to manage a large number of subscibers?
No not really. With the prefetch & slow consumer handling settings you mentioned previously, the broker shouldn't use up that much RAM for the topics. Though I'm still a bit unsure what queues are being used. -- James ------- http://radio.weblogs.com/0112098/
