[rabbitmq-discuss] Librabbitmq

[David Wragg]

Hi Pieter,

Pieter de Zwart <pdezwart at rubiconproject.com> writes:
> I am having some trouble with the librabbitmq library, and I am hoping you
> can help me out. We have managed to created a situation whereby a connection
> gets closed down, but the PHP client does not know about it yet. As a
> result, when it tries to clean itself up with amqp_channel_close(), a
> SIGPIPE is thrown and PHP gets all kinds of pissed off.
>
> I was wondering if you could help me either:
>
> 1. catch SIGPIPE in the PHP C client somehow. (I am a n00b.)
>
> 2. pass some sort of flag to the connection to ignore SIGPIPE and return
> false instead. In case you are as clueless as I am (I am sure you are not,
> but just in case) I found this:
> setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

I haven't heard of SO_NOSIGPIPE before - it seems to be only available
on OS X.

There are a couple of other options:

3. If the process sets the handler for SIGPIPE to SIG_IGN, then SIGPIPE
  will not be raised, and the offending write call will fail with EPIPE.
  A lot of UNIX processes do this, I believe; SIGPIPE is often more of a
  nuisance than a feature.  librabbitmq will propagate EPIPE, I expect.

4. If, instead of using write(2), we use send(2) and specify the
  MSG_NOSIGNAL flag, then SIGPIPE will not be raised, and the send call
  will fail with EPIPE.  It sounds like modifying amqp_channel_close to
  do this might make sense: There's little value in a SIGPIPE
  when we are trying to close the connection anyway. Unfortunately,
  MSG_NOSIGNAL is only supported by some OSes.

I suspect that (3) might be your best option, at least for now.  It's
process wide, but if PHP isn't happy about getting SIGPIPE, that is
probably quite reasonable.

David

-- 
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware