You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by snacktime <sn...@gmail.com> on 2006/10/14 01:48:37 UTC

Issues with stomp

I've been testing out activemq for a couple of days now.  We would be
using it as a standalone MQ with perl/ruby clients connecting to it.
So far, it's not been good.  Active MQ falls over without hardly
trying when using stomp.  Basically, it's easy to get it in a
condition where it thinks there are consumers or subscribers that
don't exist, and then it's impossible to read any remaining messages
in the queue.   Either there will be consumers showing that don't
exist, or subscribers showing in the broker but no consumer in the
queue.  Queue counts strangely go into negative numbers, and a restart
doesn't have any effect.  When a queue is stuck, I have also noticed
that if I try to connect as a consumer my client doesn't see anything,
but JMX shows the queue count going down by one.  And if I restart
activemq it will show that 1 transaction was recovered.

To get activemq into this state I will either forcibly disconnect a
consumer in a bad way a couple of times, or if I send enough messages
into the queue then it also locks up.  By locking up I mean consumers
cannot read from the queue, and new consumers get 'stuck' after
disconnecting, which activemq thinking they are still reading from the
queue. At the same time activemq starts eating up large chunks of
memory, going from 70mb ram to 120mb or more in a short time period.
Roughly 10mb per 10,000 very short messages.

I'm seeing most of these issues in both 4.0.1 and the latest RC of
4.0.2.  This is on freebsd 6.1 and I've tried both the native jdk1.5
and linux-blackdown 1.4.  The client is the ruby stomp client.  I am
not a java developer, but I'd be happy to provide any information that
might help solve these issues, as they are definitely prohibiting us
from using activemq.  Which is unfortunate because from everything
else I have seen there really isn't anything else in the open source
world which compares.

Chris
Payment Online Inc

Re: Issues with stomp

Posted by James Strachan <ja...@gmail.com>.
FWIW you can increase the usageManager setting in the activemq.xml to
give ActiveMQ more RAM to work with, which will delay the issue you're
seeing. BTW are you using persistent or non persistent messaging?

On 10/14/06, snacktime <sn...@gmail.com> wrote:
> On 10/13/06, Rob Davies <ra...@gmail.com> wrote:
> > Hi Chris,
> >
> > thanks for the info.  Please bear with it - I'm not sure the issue is
> > so much with Stomp  but with ActiveMQ's ability to handle large
> > volumes of messages that haven't been consumed. This is something I'
> > ve been working on improving for a while - and it should be ready end
> > of next week.
>
> That makes sense.  So far I've narrowed it down to two specific
> scenarios where things start to go crazy.  One is when a stomp
> consumer disconnects badly, and the other is when too many messages
> are in the queue, somewhere around 20,000 or so from what I've seen.
> If I just have a consumer constantly reading anything put into the
> queue I can send stuff for days and it works fine without any jumps in
> memory consumption.  Also, when it does start eating memory messages
> can't be consumed and disconnected consumers still hang around, but I
> can still put messages into the queue.  But you probably already knew
> that..
>


-- 

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

Re: Issues with stomp

Posted by snacktime <sn...@gmail.com>.
On 10/13/06, Rob Davies <ra...@gmail.com> wrote:
> Hi Chris,
>
> thanks for the info.  Please bear with it - I'm not sure the issue is
> so much with Stomp  but with ActiveMQ's ability to handle large
> volumes of messages that haven't been consumed. This is something I'
> ve been working on improving for a while - and it should be ready end
> of next week.

That makes sense.  So far I've narrowed it down to two specific
scenarios where things start to go crazy.  One is when a stomp
consumer disconnects badly, and the other is when too many messages
are in the queue, somewhere around 20,000 or so from what I've seen.
If I just have a consumer constantly reading anything put into the
queue I can send stuff for days and it works fine without any jumps in
memory consumption.  Also, when it does start eating memory messages
can't be consumed and disconnected consumers still hang around, but I
can still put messages into the queue.  But you probably already knew
that..

Re: Issues with stomp

Posted by Rob Davies <ra...@gmail.com>.
Hi Chris,

thanks for the info.  Please bear with it - I'm not sure the issue is  
so much with Stomp  but with ActiveMQ's ability to handle large  
volumes of messages that haven't been consumed. This is something I'  
ve been working on improving for a while - and it should be ready end  
of next week.

cheers,

rob

On 14 Oct 2006, at 00:48, snacktime wrote:

> I've been testing out activemq for a couple of days now.  We would be
> using it as a standalone MQ with perl/ruby clients connecting to it.
> So far, it's not been good.  Active MQ falls over without hardly
> trying when using stomp.  Basically, it's easy to get it in a
> condition where it thinks there are consumers or subscribers that
> don't exist, and then it's impossible to read any remaining messages
> in the queue.   Either there will be consumers showing that don't
> exist, or subscribers showing in the broker but no consumer in the
> queue.  Queue counts strangely go into negative numbers, and a restart
> doesn't have any effect.  When a queue is stuck, I have also noticed
> that if I try to connect as a consumer my client doesn't see anything,
> but JMX shows the queue count going down by one.  And if I restart
> activemq it will show that 1 transaction was recovered.
>
> To get activemq into this state I will either forcibly disconnect a
> consumer in a bad way a couple of times, or if I send enough messages
> into the queue then it also locks up.  By locking up I mean consumers
> cannot read from the queue, and new consumers get 'stuck' after
> disconnecting, which activemq thinking they are still reading from the
> queue. At the same time activemq starts eating up large chunks of
> memory, going from 70mb ram to 120mb or more in a short time period.
> Roughly 10mb per 10,000 very short messages.
>
> I'm seeing most of these issues in both 4.0.1 and the latest RC of
> 4.0.2.  This is on freebsd 6.1 and I've tried both the native jdk1.5
> and linux-blackdown 1.4.  The client is the ruby stomp client.  I am
> not a java developer, but I'd be happy to provide any information that
> might help solve these issues, as they are definitely prohibiting us
> from using activemq.  Which is unfortunate because from everything
> else I have seen there really isn't anything else in the open source
> world which compares.
>
> Chris
> Payment Online Inc