Hi Alexis, thanks for getting in touch with Theo.� However, I'm not sure this addresses my issue.<br><br>I think he's using "remote" here to refer to the Rabbit process on the other end of the socket from my publisher.� If that Rabbit process goes down, the publisher does receive a SIGPIPE.� However, that is actually my "local" process.� My "remote" process is the Rabbit node on another machine that holds the queue.� My publisher connects to the local Rabbit, and the local Rabbit connects to the remote Rabbit.� If the remote Rabbit goes down, there is no SIGPIPE in my publisher.<br>
<br>The hang in DESTROY was resolved by upgrading Rabbit itself.<br><br>I'll contact him myself and let you know what I find out.<br><br>Ronald<br><br><br><div class="gmail_quote">On Fri, Jun 3, 2011 at 11:47 AM, Alexis Richardson <span dir="ltr"><<a href="mailto:alexis@rabbitmq.com">alexis@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Ronald<br>
<br>
I spoke with the author, Theo Schlossnagle, who permitted to post his<br>
reply here:<br>
<br>
-<br>
You must catch SIGPIPE if you plan to handle busted writes on<br>
sockets. This is straight forward from perl.<br>
<br>
The publishes don't erroneously indicated success as the writes() and<br>
synchronous. The remote is down, but the TCP socket hasn't realized it<br>
yet... So you write(), which is fine (as the socket hasn't flushed).<br>
So, if it flushes into the kernel and the kernel knows the socket is<br>
busted -> SIGPIPE, if not, then you'll get a successful publish. �That<br>
behaviour is expected, no?<br>
<br>
The hang in DESTROY sounds like a bug -- I have not seen that one on<br>
my side. �Would like some more information -- user-space stack trace<br>
of the hung perl process w/ symbols would be awesome.<br>
<br>
You can also open a issue on github for the specific problems<br>
remaining unresolved:<br>
<br>
<a href="https://github.com/omniti-labs/Net--RabbitMQ" target="_blank">https://github.com/omniti-labs/Net--RabbitMQ</a><br>
-<br>
<br>
Hope this helps!<br>
<br>
alexis<br>
<br>
<br>
<br>
On Tue, May 31, 2011 at 6:34 PM, Ronald J Kimball<br>
<div><div></div><div class="h5"><<a href="mailto:rkimball@pangeamedia.com">rkimball@pangeamedia.com</a>> wrote:<br>
> Hi, thanks for the response.� Unfortunately, I haven't really found an<br>
> answer.<br>
><br>
> We upgraded RabbitMQ to 2.4.1, after which Net::RabbitMQ no longer hangs<br>
> when the remote server is up but the remote app is down.<br>
><br>
> However, Net::RabbitMQ still returns a false success when the remote server<br>
> or app goes down after the publisher connects to the local node.� (The queue<br>
> is located on the remote app.)<br>
><br>
> For now, we've switched to having a single node.� This decreases our<br>
> throughput slightly, but at least we don't risk dropping messages.<br>
><br>
> I think we must be doing something wrong, but I don't know what...<br>
><br>
> Ronald<br>
><br>
><br>
> On Tue, May 31, 2011 at 7:41 AM, Alexis Richardson <<a href="mailto:alexis@rabbitmq.com">alexis@rabbitmq.com</a>><br>
> wrote:<br>
>><br>
>> Ronald<br>
>><br>
>> Were you able to find an answer to this?<br>
>><br>
>> alexis<br>
>><br>
>><br>
>><br>
>> On Thu, May 19, 2011 at 9:44 PM, Ronald J Kimball<br>
>> <<a href="mailto:rkimball@pangeamedia.com">rkimball@pangeamedia.com</a>> wrote:<br>
>> > I'm trying to understand how RabbitMQ behaves under failure conditions,<br>
>> > specifically when using the Net::RabbitMQ Perl module.<br>
>> ><br>
>> > We have RabbitMQ set up with three nodes, one on the backend, which<br>
>> > holds<br>
>> > the actual queues, and two on the frontend, which receive publish<br>
>> > requests.<br>
>> ><br>
>> > RabbitMQ 2.2.0<br>
>> > Net::RabbitMQ 0.1.8<br>
>> ><br>
>> ><br>
>> > Below is the chart of behaviors that I have observed.<br>
>> ><br>
>> > "+" means the behavior is as I expected: either the message is<br>
>> > successfully<br>
>> > queued, or an error is thrown.<br>
>> > "-" means the behavior is not as I expected, but can be managed:<br>
>> > specifically, the process receives a SIGPIPE, which I can trap and<br>
>> > recover<br>
>> > from.<br>
>> > "!" means the behavior is not as I expected, and cannot be managed: the<br>
>> > message is not queued but no error is thrown and/or the process hangs.<br>
>> ><br>
>> > "App down" means I ran `rabbitmqctl stop_app`.� "Daemon down" means I<br>
>> > ran<br>
>> > `rabbitmqctl stop`.<br>
>> ><br>
>> > � As publishing process starts up:<br>
>> ><br>
>> > ��� Remote daemon up, app up<br>
>> > ����� + Everything okay<br>
>> ><br>
>> > ��� Remote daemon up, app down<br>
>> > ����� ! Net::RabbitMQ hangs when declaring queue<br>
>> ><br>
>> > ��� Remote daemon down<br>
>> > ����� + Net::RabbitMQ throws error when declaring queue<br>
>> > ������� "Declaring queue: server channel error 404, message: NOT_FOUND -<br>
>> > no<br>
>> > queue 'test' in vhost '/'"<br>
>> ><br>
>> > ��� Local daemon up, app down<br>
>> > ����� + Net::RabbitMQ throws error when connecting<br>
>> > ������� "Opening socket: Connection refused"<br>
>> ><br>
>> > ��� Local daemon down<br>
>> > ����� + Net::RabbitMQ throws error when connecting<br>
>> > ������� "Opening socket: Connection refused"<br>
>> ><br>
>> ><br>
>> > � After publishing process starts up:<br>
>> ><br>
>> > ��� Local app goes down<br>
>> > ����� - Process receives SIGPIPE<br>
>> ><br>
>> > ��� Local daemon goes down<br>
>> > ����� - Process receives SIGPIPE<br>
>> ><br>
>> > ��� Remote app goes down<br>
>> > ����� ! Net::RabbitMQ falsely indicates success when publishing, then<br>
>> > hangs<br>
>> > (in DESTROY?)<br>
>> ><br>
>> > ��� Remote daemon goes down<br>
>> > ����� ! Net::RabbitMQ falsely indicates success when publishing<br>
>> ><br>
>> ><br>
>> > ��� Local app goes down, comes back up<br>
>> > ����� - Process receives SIGPIPE<br>
>> ><br>
>> > ��� Local daemon goes down, comes back up<br>
>> > ����� - Process receives SIGPIPE<br>
>> ><br>
>> > ��� Remote app goes down, comes back up<br>
>> > ����� + Everything okay<br>
>> ><br>
>> > ��� Remote daemon goes down, comes back up<br>
>> > ����� + Everything okay<br>
>> ><br>
>> ><br>
>> > Have other people had these problems with Net::RabbitMQ?� Can we resolve<br>
>> > these issues by changing something in our RabbitMQ configuration?<br>
>> ><br>
>> ><br>
>> > thanks,<br>
>> > Ronald<br>
>> ><br>
>> ><br>
>> > P.S. Here's my script.<br>
>> ><br>
>> > #!/usr/local/bin/perl<br>
>> ><br>
>> > use strict;<br>
>> > use warnings;<br>
>> ><br>
>> > use Net::RabbitMQ;<br>
>> ><br>
>> > $| = 1;<br>
>> ><br>
>> > $SIG{'PIPE'} = sub { die "SIGPIPE\n" };<br>
>> ><br>
>> > my $mq = Net::RabbitMQ->new();<br>
>> ><br>
>> > alarm(10);<br>
>> ><br>
>> > print "Connecting\n";<br>
>> > $mq->connect('localhost', { user => 'engagement', password => '********'<br>
>> > })<br>
>> > � or die "Can't connect to RabbitMQ\n";<br>
>> ><br>
>> > print "Opening channel\n";<br>
>> > $mq->channel_open(1);<br>
>> ><br>
>> > print "Declaring exchange\n";<br>
>> > $mq->exchange_declare(1, 'ee_exchange', { durable => 1 });<br>
>> ><br>
>> > print "Declaring queue\n";<br>
>> > $mq->queue_declare(1, 'test', { durable => 1 });<br>
>> ><br>
>> > print "Binding queue\n";<br>
>> > $mq->queue_bind(1, 'test', 'ee_exchange', 'ee_test');<br>
>> ><br>
>> > alarm(0);<br>
>> ><br>
>> > print "> ";<br>
>> > <>;<br>
>> ><br>
>> > alarm(10);<br>
>> ><br>
>> > print "Publishing message\n";<br>
>> > my $rc =<br>
>> > � $mq->publish(1, 'ee_test', 'hello world!',<br>
>> > �������������� { exchange => 'ee_exchange', mandatory => 1, immediate =><br>
>> > 0<br>
>> > },<br>
>> > �������������� { delivery_mode => 2 });<br>
>> > print "Result: $rc\n";<br>
>> ><br>
>> > __END__<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > rabbitmq-discuss mailing list<br>
>> > <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">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>
><br>
><br>
</div></div></blockquote></div><br>