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>