On 7/6/06, Kuppe <kuppe@360t.com> 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/
|