Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of lists@nabble.com designates
 72.21.53.35 as permitted sender)
Message-ID: <6916848.post@talk.nabble.com>
Date: Fri, 20 Oct 2006 06:35:07 -0700 (PDT)
From: Priya Parvatikar <priya.parvatikar@ingenta.com>
To: activemq-users@geronimo.apache.org
Subject: Re: Publisher stalls but does not resume after messages have been
 consum
In-Reply-To: <6899815.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <6899815.post@talk.nabble.com>


Hi,

An update - I tried the above with a Java message producer instead of a perl
one.  So there is a Java producer that starts publishing a large number of
messages to a topic. There is a durable subscriber registered but it is
offline at the moment.

After sending about 12000 messages, the Java producer seemed to stall and
the "percentage memory used" for the broker went up to a 100% just as had
happened with the perl producer. However, when a subscriber started to
receive messages from the topic, the Java producer resumed sending messages
and the "percentage memory used" figure started going down . This was slow
at first, but picked up speed as the consumer started consuming more and
more messages.

So I think the Java producer seems to be resuming once a subscriber starts
consuming the messages and the problem of the producer not resuming seems to
occur for the perl producer. 

Also Sileshi is right - I also did not see anything for "slow down" messages
in the Stomp spec.  I guess that perhaps the broker stopped accepting
messages from the perl producer (and also the java one) when it ran out of
memory? But it couldn't get the perl producer to resume sending again?

Could you please advise me about this? 

Thanks,
Priya


Priya Parvatikar wrote:
> 
> Hi,
> 
> Could you please help me with this? I am using ActiveMQ 4.0.1 and have a
> problem. 
> 
> I have written a perl Stomp message producer that tries to publish a large
> number of messages to a topic in a short amount of time. This topic has a
> durable subscriber registered for it, but the subscriber is offline at the
> time that the publisher starts publishing. The messages are persisted to a
> Postgresql database. I have disabled journaling. The size of the message
> body is approximately 2Kb. The memory limit for the broker in the JMX
> console has been set to 104857600.
> 
> When the producer starts publishing messages, the EnqueueCounter for the
> topic in the JMX console starts going up as expected. Also records are
> added to the activemq_msgs table in the database as expected. 
> 
> However, after a certain number of messages have been published (~10,000),
> the message producer seems to stop sending messages. It does not die and
> the socket connection with the ActiveMQ server is still alive, but the
> publisher just seems to stall. I had a look at
> http://activemq.org/site/what-happens-with-a-fast-producer-and-slow-consumer.html
> and it looks like the message producer is told to slow down because there
> are a large number of unconsumed messages? 
> 
> I then started off the durable subscriber that picked up those messages. I
> thought that once the number of pending messages would go down, the
> stalled publisher would resume sending. However that did not seem to
> happen even after the subscriber had received all the messages (the
> enqueue and dequeue counter were the same in the JMX console). I am not
> sure if I am understanding this correctly , am I correct in thinking that
> the perl producer will resume sending messages after the durable
> subscriber comes online and consumes the messages waiting?
> 
> Could someone please advise me about this?
> 
> Many Thanks,
> Priya
> 
> 

-- 
View this message in context: http://www.nabble.com/Publisher-stalls-but-does-not-resume-after-messages-have-been-consumed-tf2474377.html#a6916848
Sent from the ActiveMQ - User mailing list archive at Nabble.com.