<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi Michael,<br>
<br>
<br>
Killing the app is not recommended, because there may be unflushed
buffers in the client - that may cause some messages not to be
delivered and others to be delivered incompletely (which the broker
will eventually drop). It is always recommended to close all the
channels and all the connections before shutting down the application.<br>
<br>
FWIW, RabbitMQ should detect when the socket closes (for whatever
reason) and remove those connections pretty quickly (even if you didn't
do a clean shutdown). I wonder why you still see the connections after
killing the app.<br>
<br>
Anyway, I don't see how that could interfere with the delays problem.<br>
<br>
<br>
Rgds,<br>
Vlad.<br>
<br>
<br>
On 09/16/2010 09:01 AM, Michael Burns wrote:
<blockquote
cite="mid:AANLkTin7ANf6kvYfgZ4dXFRhBHu616AzCMqxkYaeBknE@mail.gmail.com"
type="cite">Hi Alex,<br>
Haven't had a chance to try with 2.0.0 but will do so soon. <br>
<br>
I've noticed sometimes that there are extra connections hanging about
on the RabbitMQ broker (using rabbitmqctl list_connections).<br>
It's possible sometimes in our consumers that we are not always closing
the connection cleanly (sometimes people are simply killing their app
rather than shutting down cleanly).<br>
<br>
Could this somehow explain why we experience these delays? <br>
<br>
Cheers,<br>
Michael<br>
<br>
<div class="gmail_quote">On Wed, Sep 8, 2010 at 10:46 AM, Alexandru
Scvorţov <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:alexandru@rabbitmq.com">alexandru@rabbitmq.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<div class="im"><br>
> Cool I'll try upgrading and see if that helps.<br>
<br>
</div>
Any luck with 2.0.0?<br>
<br>
Cheers,<br>
Alex<br>
<div>
<div class="h5"><br>
On Mon, Sep 06, 2010 at 09:28:41AM +0100, Michael Burns wrote:<br>
> ><br>
> > When the slowdown occurs, does rabbit pick up speed a bit
later? Or do<br>
> > you have to restart it or something else of the sort?<br>
> ><br>
><br>
> Yes it will pick up speed after a bit without a server restart.<br>
><br>
><br>
> ><br>
> > When it occurs, does list_queues show a large number of
messages? If<br>
> > so, you're probably not ack'ing the messages after consuming
them.<br>
> ><br>
><br>
> No. At the moment we're putting a very small number of messages
through the<br>
> system. When the delay occurs I'm usually seeing one or two
messages on the<br>
> queue. Eventually the messages will come through.<br>
> Is there anything we could whilst the message is on the queue that
would<br>
> give more information as to why it is not being delivered?<br>
><br>
><br>
><br>
><br>
> ><br>
> > On an unrelated note, 2.0.0 is out, so you might want to
upgrade.<br>
> ><br>
><br>
> Cool I'll try upgrading and see if that helps.<br>
><br>
> Cheers,<br>
> Michael<br>
><br>
><br>
> ><br>
> > Cheers,<br>
> > Alex<br>
> ><br>
> > On Fri, Sep 03, 2010 at 11:38:09AM +0100, Michael Burns wrote:<br>
> > > Hi Alex,<br>
> > > I ran the multicast client and am getting speeds like:<br>
> > ><br>
> > > sending rate: 3550 msg/s, basic returns: 0 ret/s<br>
> > > recving rate: 3461 msg/s, min/avg/max latency:
11931197/12253891/12477030<br>
> > > microseconds<br>
> > ><br>
> > > If I let it run for a bit then sometimes both the
sending and receiving<br>
> > rate<br>
> > > drop significantly e.g.:<br>
> > ><br>
> > > sending rate: 638 msg/s, basic returns: 0 ret/s<br>
> > > recving rate: 628 msg/s, min/avg/max latency:
11788406/12363242/12735553<br>
> > > microseconds<br>
> > ><br>
> > > Not sure if this drop is indicative of anything?<br>
> > ><br>
> > > We're using the java client 1.8.1, the broker is
rabbitmq_server-1.8.1<br>
> > ><br>
> > > Thanks<br>
> > > Michael<br>
> > ><br>
> > > On Fri, Sep 3, 2010 at 9:29 AM, Alexandru Scvorţov<br>
> > > <<a moz-do-not-send="true"
href="mailto:alexandru@rabbitmq.com">alexandru@rabbitmq.com</a>>wrote:<br>
> > ><br>
> > > > Hi Michael,<br>
> > > ><br>
> > > > > We are putting a very low volume of messages
through and have<br>
> > sometimes<br>
> > > > had<br>
> > > > > to wait up to 15 minutes for a single message
to be delivered (at the<br>
> > > > time<br>
> > > > > this was the only message in the system).<br>
> > > ><br>
> > > > That sounds strage. Are you up for a bit of
debugging?<br>
> > > ><br>
> > > > Download the java client,<br>
> > > > <a moz-do-not-send="true"
href="http://www.rabbitmq.com/java-client.html" target="_blank">http://www.rabbitmq.com/java-client.html</a><br>
> > > ><br>
> > > > Unpack it, and run<br>
> > > > sh runjava.sh com.rabbitmq.examples.MulticastMain
-x 1 -y 1<br>
> > > ><br>
> > > > That command will run one of our example programmes
in a way that<br>
> > > > matches your setup: 1 producer (-x 1) and 1
consumer (-y 1).<br>
> > > ><br>
> > > > When I run it, I get speeds like:<br>
> > > > recving rate: 6052 msg/s, min/avg/max latency:
1063522/1118048/1164637<br>
> > > > microseconds<br>
> > > > sending rate: 6419 msg/s, basic returns: 0 ret/s<br>
> > > ><br>
> > > > If you're getting similar speeds, there's probably
something wrong with<br>
> > > > the consumers/producers. If not, it might be
something to do with the<br>
> > > > server.<br>
> > > ><br>
> > > > Could you please try it?<br>
> > > ><br>
> > > > Also, which version the broker and which client are
you using?<br>
> > > ><br>
> > > > Cheers,<br>
> > > > Alex<br>
> > > ><br>
> > > > On Fri, Sep 03, 2010 at 09:03:25AM +0100, Michael
Burns wrote:<br>
> > > > > Hi,<br>
> > > > ><br>
> > > > > We're just starting out with RabbitMQ and have
a very simple setup:<br>
> > one<br>
> > > > > queue, one producer doing a basicPublish and
one consumer doing a<br>
> > > > > basicConsume using QueueingConsumer.<br>
> > > > ><br>
> > > > > For the most part it works fine however at
fairly regular intervals<br>
> > we<br>
> > > > are<br>
> > > > > finding that messages remain on the queue for
a considerable period<br>
> > > > before<br>
> > > > > being delivered to the consumer.<br>
> > > > ><br>
> > > > > We are putting a very low volume of messages
through and have<br>
> > sometimes<br>
> > > > had<br>
> > > > > to wait up to 15 minutes for a single message
to be delivered (at the<br>
> > > > time<br>
> > > > > this was the only message in the system).<br>
> > > > ><br>
> > > > > In all cases the messages are eventually
delivered.<br>
> > > > ><br>
> > > > > I dont know where to start debugging this as
there is nothing in the<br>
> > > > > RabbitMQ logs thats suggests something is
going wrong - could anyone<br>
> > > > point<br>
> > > > > me in the right direction as to what may be
causing this?<br>
> > > > ><br>
> > > > > Many Thanks,<br>
> > > > > Michael<br>
> > > ><br>
> > > > > _______________________________________________<br>
> > > > > rabbitmq-discuss mailing list<br>
> > > > > <a moz-do-not-send="true"
href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> > > > > <a moz-do-not-send="true"
href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss"
target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
> > > ><br>
> > > ><br>
> ><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rabbitmq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>
<a class="moz-txt-link-freetext" href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
</blockquote>
</body>
</html>