<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">
<!--
p
{margin-top:0;
margin-bottom:0}
p
{margin-top:0;
margin-bottom:0}
p
{margin-top:0;
margin-bottom:0}
-->
</style>
</head>
<body>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">Dear Alan,<br>
<br>
I download rabbitmq-c master package from and tried newly added <span class="nf">
<b>amqp_simple_wait_frame_noblock</b> API. I modified amqp_listen.c example and instead of amqp_simple_wait_frame I used
</span><span class="nf"><b>amqp_simple_wait_frame_noblock </b>with different timeout values. However this API is failing immediately with return value as -13. What this return value means? Is there any other way of using timeout so that if I don't receive a
frame within say 10ms I can reject that message.<br>
<br>
Another problem I am facing with <b>amqp_basic_reject</b> API. In </span><span class="nf"><span class="nf">amqp_listen.c example I called this API (with requeue=1) and I got following console output. After that it is not able to receive any message sent by
amqp_send_string example.<br>
<br>
00000000: 48 65 6C 6C 6F 20 57 6F : 72 6C 64 Hello World<br>
0000000B:<br>
Result 0<br>
Frame type 1, channel 1<br>
Method AMQP_CHANNEL_CLOSE_METHOD<br>
<br>
</span>One more problem I would like to report. I have created a client 7 different queues with 7 different channels and bound with 7 different binding keys on the same connection with direct exchange. The listening part of these 7 queues are with 7 different
threads listening for server input. When I am sending message from server with corresponding routing keys the messages are delivered to different queue than the expected queue. (I believe it is called
</span><span class="nf">Shunting messages from one queue to another). What could be the problem? Do I have to do something from rabbitmq server to targeted delivery? I tried by making queues exclusive but got the same result.<br>
<br>
Please help.<br>
<br>
Thanks and regards,<br>
Shashank<br>
</span>
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<div>
<div dir="ltr"><br>
<div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername"></b><span dir="ltr"><<a href="mailto:rabbitmq-discuss-request@lists.rabbitmq.com" target="_blank">rabbitmq-discuss-request@lists.rabbitmq.com</a>></span><br>
Date: Wed, Jun 26, 2013 at 4:30 PM<br>
Subject: rabbitmq-discuss Digest, Vol 73, Issue 27<br>
To: <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<br>
<br>
Send rabbitmq-discuss mailing list submissions to<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a 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>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rabbitmq-discuss-request@lists.rabbitmq.com" target="_blank">
rabbitmq-discuss-request@lists.rabbitmq.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rabbitmq-discuss-owner@lists.rabbitmq.com" target="_blank">
rabbitmq-discuss-owner@lists.rabbitmq.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of rabbitmq-discuss digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Determining Required Erlang Version for Upgrade (Richard Raseley)<br>
2. Re: RabbitMQ Consumer timeout (Alan Antonuk)<br>
3. Re: RabbitMQ's Mirroring results in weird behavior when slave<br>
goes down (thomas)<br>
4. Re: Determining Required Erlang Version for Upgrade<br>
(Michael Klishin)<br>
5. Re: rabbitmq Error:{cannot_discover_cluster, "the nodes<br>
provided are either offline or not running"} (Emile Joubert)<br>
6. Re: Determining Required Erlang Version for Upgrade<br>
(Emile Joubert)<br>
7. Re: RabbitMQ won't start after the disk went full (Emile Joubert)<br>
8. Re: RabbitMQ's Mirroring results in weird behavior when slave<br>
goes down (Tim Watson)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 25 Jun 2013 12:39:15 -0700<br>
From: Richard Raseley <<a href="mailto:richard@raseley.com" target="_blank">richard@raseley.com</a>><br>
Subject: [rabbitmq-discuss] Determining Required Erlang Version for<br>
Upgrade<br>
To: RabbitMQ-Discuss Mailing List<br>
<<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Message-ID:<br>
<CAO=<a href="mailto:6ox_tTVUHNnd4VwPr2zO%2BiGnjb1Kr5fYT0OEadj-urYRiAA@mail.gmail.com" target="_blank">6ox_tTVUHNnd4VwPr2zO+iGnjb1Kr5fYT0OEadj-urYRiAA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
I am in the process of drafting a plan to upgrade several 3.0.x instances<br>
to 3.1.2. I cannot seem to find in the release notes the specific version<br>
of Erlang that is required for the new versions.<br>
<br>
Would someone please direct me to a version requirement matrix (assuming<br>
one exists)?<br>
<br>
Regards,<br>
<br>
Richard<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130625/196f9e67/attachment.html" target="_blank">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130625/196f9e67/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 25 Jun 2013 17:36:48 -0700<br>
From: Alan Antonuk <<a href="mailto:alan.antonuk@gmail.com" target="_blank">alan.antonuk@gmail.com</a>><br>
Subject: Re: [rabbitmq-discuss] RabbitMQ Consumer timeout<br>
To: Discussions about RabbitMQ <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Message-ID:<br>
<CAAt2poJAP5z0-gsdNFaNaH0qzR_FLcxwK_tQEA_tmb=<a href="mailto:d2CoZiA@mail.gmail.com" target="_blank">d2CoZiA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Antony;<br>
<br>
rabbitmq-c has very recently added an API that allows for specifying a<br>
timeout when waiting for frames from the broker (see<br>
<a href="https://github.com/alanxz/rabbitmq-c/blob/master/librabbitmq/amqp.h#L495" target="_blank">https://github.com/alanxz/rabbitmq-c/blob/master/librabbitmq/amqp.h#L495</a> ).<br>
With this API is possible to implement something with a similar effect.<br>
<br>
I will warn you that this is only in the development branch and thus hasn't<br>
received the same amount of testing that tagged versions have, but I would<br>
encourage you to try it out and report back any issues that come up.<br>
<br>
-Alan<br>
<br>
<br>
On Tue, Jun 25, 2013 at 4:56 AM, antony <<a href="mailto:antony.pulicken@gmail.com" target="_blank">antony.pulicken@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> This is my scenario:<br>
><br>
> I have multiple instances of listeners waiting on different temp queues. In<br>
> some of the cases, there won't be any messages published to these temp<br>
> queues and I want these listeners to timeout so that it can free up the<br>
> connections.<br>
><br>
> I guess in Java, we can achieve this by using the overloaded method in the<br>
> QueueingConsumer class that takes timeout as a parameter as shown below:<br>
><br>
><br>
> /QueueingConsumer.Delivery delivery = null;<br>
> long timeout = 2 * 60 * 1000; // 2 minutes in milliseconds<br>
> delivery = queuingConsumer.nextDelivery(*timeout*);<br>
> if (delivery == null) {<br>
> // shut down your consumer here - no events arrived<br>
> // before the timeout was reached<br>
> }<br>
> else {<br>
> // process the delivered message here<br>
> }/<br>
><br>
><br>
> 1) Does RabbitMQ C client also has a similar feature ?<br>
><br>
> 2) Are there better approaches to handle this timeouts ?<br>
><br>
> Please let me know.<br>
><br>
> Thanks and Regards,<br>
> Antony.<br>
><br>
><br>
><br>
><br>
> --<br>
> View this message in context:<br>
> <a href="http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-Consumer-timeout-tp27590.html" target="_blank">
http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-Consumer-timeout-tp27590.html</a><br>
> Sent from the RabbitMQ mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> rabbitmq-discuss mailing list<br>
> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> <a 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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130625/3468600c/attachment-0001.htm" target="_blank">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130625/3468600c/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 25 Jun 2013 22:24:26 -0700 (PDT)<br>
From: thomas <<a href="mailto:taihock@gmail.com" target="_blank">taihock@gmail.com</a>><br>
Subject: Re: [rabbitmq-discuss] RabbitMQ's Mirroring results in weird<br>
behavior when slave goes down<br>
To: <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
Message-ID: <<a href="mailto:1372224266044-27611.post@n5.nabble.com" target="_blank">1372224266044-27611.post@n5.nabble.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi Tim,<br>
<br>
Thanks for the reply. I am using rabbitmq 3.1.1 with autoheal for<br>
cluster_partition_handling.<br>
<br>
My test is just to find out the behavior of rabbitmq master should its slave<br>
goes down. For my case, initially I will have rabbit@A, rabbit@B and<br>
rabbit@C running. Then I will send out messages from client to rabbit@A<br>
which is the master throughout the test. Soon after the client started to<br>
send out messages, I will bring down a slave which in my case is rabbit@B by<br>
closing its network connection.<br>
<br>
I have changed the net_ticktime to 60 and carry out the same test using the<br>
same code but this time round i increases the number of messages to 500,000<br>
so as to better observe the behavior of sending messages for more than a<br>
minute.<br>
<br>
My observation is still similar to that of my previous test where<br>
net_ticktime is 2.<br>
Approximately 10 seconds after I shut down the network connection of<br>
rabbit@B, the sending of messages to rabbit@A comes to a pause for close to<br>
a minute and then continues as per normal.<br>
<br>
Trying the same test but with no mirroring does not have any disruption.<br>
<br>
By the way, I have try out the same test for rabbitmq mirroring except that<br>
there will be a delay of 10ms between sending every message and there was no<br>
disruption.<br>
<br>
>From my observation it can be seen that RabbitMQ server will exhibit weird<br>
behavior under stress condition when a slave goes down. I presume this weird<br>
behavior will only surface under stress condition.<br>
<br>
Is there a rough estimate for the maximum load that a RabbitMQ server can<br>
take per second for mirroring? Thanks.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-s-Mirroring-results-in-weird-behavior-when-slave-goes-down-tp27572p27611.html" target="_blank">
http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-s-Mirroring-results-in-weird-behavior-when-slave-goes-down-tp27572p27611.html</a><br>
Sent from the RabbitMQ mailing list archive at Nabble.com.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 26 Jun 2013 12:19:53 +0400<br>
From: Michael Klishin <<a href="mailto:michael.s.klishin@gmail.com" target="_blank">michael.s.klishin@gmail.com</a>><br>
Subject: Re: [rabbitmq-discuss] Determining Required Erlang Version<br>
for Upgrade<br>
To: Discussions about RabbitMQ <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Message-ID:<br>
<<a href="mailto:CAE3HoVQG8o6uiMGCU2RmasAv3qVObSF9EdN-%2BYKqe6-Scjd%2B-w@mail.gmail.com" target="_blank">CAE3HoVQG8o6uiMGCU2RmasAv3qVObSF9EdN-+YKqe6-Scjd+-w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2013/6/25 Richard Raseley <<a href="mailto:richard@raseley.com" target="_blank">richard@raseley.com</a>><br>
<br>
> I am in the process of drafting a plan to upgrade several 3.0.x instances<br>
> to 3.1.2. I cannot seem to find in the release notes the specific version<br>
> of Erlang that is required for the new versions.<br>
<br>
<br>
Richard,<br>
<br>
I don't think the version requirement changed between 3.0.x and 3.1.x.<br>
--<br>
MK<br>
<br>
<a href="http://github.com/michaelklishin" target="_blank">http://github.com/michaelklishin</a><br>
<a href="http://twitter.com/michaelklishin" target="_blank">http://twitter.com/michaelklishin</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130626/45de3926/attachment-0001.htm" target="_blank">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130626/45de3926/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 26 Jun 2013 10:22:40 +0100<br>
From: Emile Joubert <<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>><br>
Subject: Re: [rabbitmq-discuss] rabbitmq<br>
Error:{cannot_discover_cluster, "the nodes provided are either offline<br>
or not running"}<br>
To: Luis Rodriguez <<a href="mailto:lrodriguez1995@yahoo.com" target="_blank">lrodriguez1995@yahoo.com</a>>, Discussions about<br>
RabbitMQ <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Message-ID: <<a href="mailto:51CAB2E0.9010805@rabbitmq.com" target="_blank">51CAB2E0.9010805@rabbitmq.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
Hi<br>
<br>
On 25/06/13 18:38, Luis Rodriguez wrote:<br>
> I am running a windows host machine along with three vm's with centos<br>
> 5.9 , rabbitmq-server-3.0.3, and erlang installed on all three nodes.<br>
<br>
Make sure all nodes are using the same version of Erlang.<br>
<br>
> (I am able to ping between nodes fine)<br>
<br>
A number of TCP ports need to be open between cluster nodes, which ping<br>
doesn't guarantee. See<br>
<br>
<a href="http://www.rabbitmq.com/clustering.html#firewall" target="_blank">http://www.rabbitmq.com/clustering.html#firewall</a><br>
<br>
> the cookie hash however, doesn't change regardless of how many times<br>
> I stop (rabbitmqctl stop) and start.. I don't really know what I'm<br>
> missing.<br>
<br>
If you change the .erlang.cookie and the cookie hash doesn't change then<br>
you are probably copying to the wrong directory. You can discover a<br>
running node's own idea of where its home directory is by executing<br>
<br>
rabbitmqctl eval 'init:get_argument(home).'<br>
<br>
Also take note that the cookie and the cookie hash will not be the same.<br>
The hash is displayed in diagnostic output instead of the cookie as a<br>
security precaution. If you have all the cookies synchronised correctly<br>
then the hashes will also be the same.<br>
<br>
> when I do rabbitctl join_cluster I get: rabbitmq<br>
> Error:{cannot_discover_cluster,"the nodes provided are either offline<br>
> or not running"}<br>
<br>
As per the troubleshooting guide<br>
<br>
<a href="http://www.rabbitmq.com/troubleshooting.html" target="_blank">http://www.rabbitmq.com/troubleshooting.html</a><br>
<br>
if that message is accompanied by a broker logfile entry "Connection<br>
attempt from disallowed node" then the erlang cookies are not set up<br>
correctly. Otherwise the problem is network related.<br>
<br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 26 Jun 2013 10:25:52 +0100<br>
From: Emile Joubert <<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>><br>
Subject: Re: [rabbitmq-discuss] Determining Required Erlang Version<br>
for Upgrade<br>
To: Discussions about RabbitMQ <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Message-ID: <<a href="mailto:51CAB3A0.8070707@rabbitmq.com" target="_blank">51CAB3A0.8070707@rabbitmq.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
Hi Richard,<br>
<br>
On 25/06/13 20:39, Richard Raseley wrote:<br>
<br>
> Would someone please direct me to a version requirement matrix (assuming<br>
> one exists)?<br>
<br>
See <a href="http://www.rabbitmq.com/which-erlang.html" target="_blank">http://www.rabbitmq.com/which-erlang.html</a><br>
<br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 26 Jun 2013 10:35:45 +0100<br>
From: Emile Joubert <<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>><br>
Subject: Re: [rabbitmq-discuss] RabbitMQ won't start after the disk<br>
went full<br>
To: Discussions about RabbitMQ <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Cc: photon <<a href="mailto:faycal.noushi@gmail.com" target="_blank">faycal.noushi@gmail.com</a>><br>
Message-ID: <<a href="mailto:51CAB5F1.20202@rabbitmq.com" target="_blank">51CAB5F1.20202@rabbitmq.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
Hi,<br>
<br>
On 25/06/13 14:38, photon wrote:<br>
<br>
> I have an issue concerning RabbitMQ. Once my disk got full, RabbitMQ became<br>
> unusable. This didn't change even after i made the disk usage drop<br>
> dramatically.<br>
<br>
You either need to free up more space or lower the disk_free_limit. See<br>
the configuration guide:<br>
<br>
<a href="http://www.rabbitmq.com/configure.html" target="_blank">http://www.rabbitmq.com/configure.html</a><br>
<br>
> Error description:<br>
> {error,corrupt_cluster_status_files,[]}<br>
<br>
This is a separate problem and can be solved either by removing the<br>
entire Mnesia directory or by removing the cluster_nodes.config file in<br>
the Mnesia directory and reclustering if necessary.<br>
<br>
> =INFO REPORT==== 25-Jun-2013::09:10:49 ===<br>
> Disk free space insufficient. Free bytes:645095424 Limit:1000000000<br>
<br>
<br>
This shows that there is insufficient free disk space. The broker will<br>
not accept any messages until there is enough free disk space. See<br>
<br>
<a href="http://www.rabbitmq.com/memory.html#diskfreesup" target="_blank">http://www.rabbitmq.com/memory.html#diskfreesup</a><br>
<br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 26 Jun 2013 11:38:36 +0100<br>
From: Tim Watson <<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>><br>
Subject: Re: [rabbitmq-discuss] RabbitMQ's Mirroring results in weird<br>
behavior when slave goes down<br>
To: Discussions about RabbitMQ <<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><br>
Message-ID: <<a href="mailto:2F050250-E7F1-4543-B3C3-239885F7C9CB@rabbitmq.com" target="_blank">2F050250-E7F1-4543-B3C3-239885F7C9CB@rabbitmq.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi Thomas,<br>
<br>
Here are my thoughts (inline below). I'm not the greatest clustering/HA expert, but from what I can gather, I think what you're seeing might be a result of the combination of a network partition and the `autoheal' mode.<br>
<br>
On 26 Jun 2013, at 06:24, thomas wrote:<br>
<br>
> Hi Tim,<br>
><br>
> Thanks for the reply. I am using rabbitmq 3.1.1 with autoheal for<br>
> cluster_partition_handling.<br>
><br>
> My test is just to find out the behavior of rabbitmq master should its slave<br>
> goes down.<br>
<br>
This is clearly documented on the website - RabbitMQ clusters /do not/ handle network partitions well. Things will probably go wrong. If the only issue you're running into is a busy producer getting blocked then that's great - the worst cases could have involved
lost messages and all sorts.<br>
<br>
Now, the intention with HA is *not* to go belly up in the face of disappearing slaves - quite the opposite. Quite why the master is suddenly blocking the producer I'm not sure - I'll discuss this with the rest of the team but it doesn't sound quite right to
me.<br>
<br>
> Approximately 10 seconds after I shut down the network connection of<br>
> rabbit@B, the sending of messages to rabbit@A comes to a pause for close to<br>
> a minute and then continues as per normal.<br>
><br>
<br>
Just to be clear, in a RabbitMQ cluster there is no concept of a master node - only mirror queues introduce the master/slave concept, and then only for queues that are mirrored. Each mirrored queue's master can end up on different nodes, depending on which
you were connect to when it was declared.<br>
<br>
> Trying the same test but with no mirroring does not have any disruption.<br>
><br>
<br>
That is not surprising, since the queue you're connected to isn't trying to replicate to any other nodes.<br>
<br>
> By the way, I have try out the same test for rabbitmq mirroring except that<br>
> there will be a delay of 10ms between sending every message and there was no<br>
> disruption.<br>
><br>
<br>
Can you share your test code? I'm surprised there is such a big difference, but still... If you've got a decent automated test that consistently replicates this failure mode and you're able to share it, we might be able to use it to make improvements to partition
handling in the future. If not code, a test script (and description of how you're disabling the network link) with precise steps would do.<br>
<br>
> From my observation it can be seen that RabbitMQ server will exhibit weird<br>
> behavior under stress condition when a slave goes down. I presume this weird<br>
> behavior will only surface under stress condition.<br>
><br>
<br>
As I've stated before, clustering is not designed to handle network partitions. In previous versions of rabbit, when a partition occurred it was up to a system administrator to handle it. This usually involved stopping some (or all) of the nodes and restarting
them. The 'autoheal' feature simply attempts to replicate what a sysadmin might do, and therefore (whilst cluster nodes are restarting) there can be delays. The intention is not to block the master (or producers), but depending on how the cluster partition
is handled, that might be one of the potential side effects.<br>
<br>
We will certainly take a look to see if this is avoidable - I can't comment on that right now - and being able to repeat the tests could help with that too.<br>
<br>
> Is there a rough estimate for the maximum load that a RabbitMQ server can<br>
> take per second for mirroring? Thanks.<br>
><br>
<br>
I'm not sure whether mirroring is really the problem here. Mirrored queues can handle plenty of load, although there /is/ some performance slow down due to replication (and esp. so if you're using publisher confirms) but there is a not a specific limit - this
is hardware/resource and use-case dependent. I suspect the problem /you/ have could be a combination of network partition and cluster partition resolution (i.e., autoheal) mode.<br>
<br>
Based on <a href="http://www.rabbitmq.com/partitions.html" target="_blank">http://www.rabbitmq.com/partitions.html</a>, what I'd suggest is that you change 'autoheal' to 'ignore' and try your test again. That will either confirm or eliminate my suspicion quickly
enough.<br>
<br>
Cheers,<br>
Tim<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a 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>
End of rabbitmq-discuss Digest, Vol 73, Issue 27<br>
************************************************<br>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Navy" size="2"><br>
DISCLAIMER:<br>
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or
all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.<br>
</font>
</body>
</html>