activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Broker Hung With Following VM Dump
Date Thu, 01 Jun 2006 11:55:37 GMT
BTW a quick fix for your issues of the broker running out of available
RAM is to just use durable queues which can handle massive queues
(millions of messages) without any lockups.

If you don't really require the producers to block until the messages
are on disk (which can slow things down considerably) just enable
async sending....

http://incubator.apache.org/activemq/async-sends.html

Generally speaking, if you have slow consumers on queues you are
generally better off using durable queues then ActiveMQ doesn't have
to try and keep all the messages on a queue in RAM and so have to
block producers etc.

Another option is to set a massive value in the usage manager (but
that is generally just delaying the inevitable).


On 5/31/06, Gerdes, Mike <Mike.Gerdes@airbus.com> wrote:
>
> A few more things that I noticed:
>
> I have tried RC2 same problem.
>
> I have set the memory limits for the queues and topics from giga huge (the default) to
50mb. Now it is visible, that the memory usage of the queue also raises and doesn't sink again.
>
> I think this has to do with the usagemanager. But not really sure why and how. Maybe
that the usagemanagers of the queues want more memory for some reason and report this to the
broker usagemanager. Now the queues have much more memory available and request more and more
till the broker usagemanager reaches 100% and stops, because it can't offer more memory.
> The problem now is that the queues don't free their memory...
>
> -----Urspr√ľngliche Nachricht-----
> Von: Gerdes, Mike
> Gesendet: Mittwoch, 31. Mai 2006 15:09
> An: activemq-users@geronimo.apache.org
> Betreff: AW: Broker Hung With Following VM Dump
>
>
>
>
> hi,
>
> I have done a bit testing and I am able to reproduce my problem all the time. Here is
what I observed:
>
> All consumers and producers are listening and posting on the same queue.
>
> First 1 consumer, 1 producer -> no memory problems
> Second 1 consumer, 2 producers -> no memory problems
> Third 2 consumers, 1 producer -> memory problem, the memory raises till it hits 100
and then the clients die
> Fourth 2 consumers, 2 producers -> memory problem, the memory raises till it hits
100 and then the clients die
>
> Even when I kill the clients, before memory reaches 100, it doesn't frees the memory
and it stays at the fixed size.
>
> I am also using a AMQ post 10.05.2006
>
> -----Urspr√ľngliche Nachricht-----
> Von: Attila_Szegedi [mailto:nabble2@szegedi.org]
> Gesendet: Mittwoch, 31. Mai 2006 13:22
> An: activemq-users@geronimo.apache.org
> Betreff: Re: Broker Hung With Following VM Dump
>
>
>
>
> Now, I noticed that the Broker object in JMX does report
> MemoryPercentageUsed=100, but I can't fathom why. Also, I now split the
> processors for queues A and B into separate set of sessions, but still can't
> get it to work - I believe the MemoryPercentageUsed=100 is to blame. I'll
> try restarting the broker with higher memory, but this is rather problematic
> regardless
> --
> View this message in context: http://www.nabble.com/Broker+Hung+With+Following+VM+Dump-t1627677.html#a4642632
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
>
>
> This mail has originated outside your organization,
> either from an external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
> This mail has originated outside your organization, either from an external partner or
the Global Internet. Keep this in mind if you answer this message.
>
>
>
> This mail has originated outside your organization,
> either from an external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
> This mail has originated outside your organization, either from an external partner or
the Global Internet. Keep this in mind if you answer this message.
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message