PHP Warning when interupting consumer with a signal.

[Stubbs]

Warning: stream_select(): unable to select [4]: Interrupted system call (max_fd=7) in /Users/stu/Dropbox/im_british_so_i_know_how_to_queue/src/chapter5/vendor/videlalvaro/php-amqplib/PhpAmqpLib/Wire/IO/StreamIO.php on line 103

If you add a signal handler, when a signal is caught this warning is output.

I've changed the basic wait loop to look like this:

    while (count($channel->callbacks) && $this->continue) {
        try {
            $channel->wait(null, false, 1);
        } catch (\PhpAmqpLib\Exception\AMQPTimeoutException $e) {
            // Do nothing.
        } catch (\PhpAmqpLib\Exception\AMQPRuntimeException $e) {
            // Do nothing.
        }
    }

The timeout exception is expected, without the timeout the signalhandler never gets called, I guess because the stream stuff lower down is non tickable.

The AMQPRuntimeException is thrown by AMQPReader::wait because the call to select returns false, I just catch both exceptions & do nothing with them

I wonder if there's a better way to handle this? Before throwing either of the exceptions, check the result of socket_last_error and if the result isn't 0 or 10, throw the error? That way you can add @ to mask the warning & still get errors when required.

10 is the error code returned by socket_last_error when it is interrupted.

If this sounds like a good idea, I can send you a pull request with the changes.

[bmewburn]

I'm having the exact same issue. I have a consumer that may run as a daemon and I'm catching the timeout so I can call pcntl_dispatch() but I still get a stream_select error and exception at times. I'd be interested in any fixes or further investigation.

[Stubbs]

@bmewburn Can you show me the code you're when you catch the timeout?

[bmewburn]

@Stubbs my code is very similar to yours above. I'm wondering if the timeout is even necessary, I call pcntl_dispatch() within my consume callback to gracefully exit on signal between messages when the queue is full. When the queue is empty socket_select blocks but returns false when interrupted with a signal so then I can exit gracefully there as well. But I think it would be nice if the errors were suppressed, then checked and a specific exception thrown for signal interrupts instead of a generic runtime exception.

[Stubbs]

I found that the wait() command isn't tickable, which means your interrupt handler doesn't get called until you receive a message, so if you have a very low volume queue you could be waiting a long time for the queue to stop.

[monkeyphysics]

I'm running into exactly this issue. Unfortunately the wait() isn't tickable and interrupts like SIGINT won't get handled until after some data is received.

I'm curious for your changes @Stubbs - do you have a public fork?

[fprochazka]

Guys, the right way to do it is like this

[monkeyphysics]

Thanks for this @fprochazka. However, that's some serious error_handler juggling. I do like how it ultimately replaces the PHP Error with an AMQPRuntimeException. Hmmm, not sure.

Either way, any solution to this problem must use wait() with a timeout. Is there any significant performance difference compared to using wait() without a timeout?

[fprochazka]

@monkeyphysics yeah, it's hacky as fuck, but it works flawlesly :)

The problem is, that when you don't set the timeout, the signals don't interrupt the stream_select and you cannot effectively catch the pcntl signals.

[monkeyphysics]

@fprochazka, thanks for your responses again. I might give this approach a try.

I understand the necessity of using a timeout, but am just wondering about any consequences this has on performance.

[fprochazka]

It's a background job, who cares about seconds :) (just kidding, it's fast)

[monkeyphysics]

@fprochazka, I implemented your approach. For some reason, I now randomly and rarely get an AMQPTimeoutException in the outer try block (which ends up uncaught..)

Do you have any idea how this could happen? To me it seems there's no way AMQPTimeoutException could occur outside the wait()...

[fprochazka]

@monkeyphysics because you're using pcnt signals which interrupt the stream_select with timeout when needed, you can set the timeout realy high. I have it at two minutes. You have to catch the exception. The exception shouldn't be random.

So unfortunatelly, you get an exception every two minutes (which I throw away), but... It works :)

[monkeyphysics]

@fprochazka, thanks for your response again. I understand the need to catch the AMQPTimeoutException in the inner try block. However, I'm now getting a random and rare AMQPTimeoutException in the outer try block, which is not caught here.

[fprochazka]

@monkeyphysics well, there shouldn't be one, and I'm pretty sure I don't get any there.

[monkeyphysics]

For completing this discussing, I eventually found the last issue (uncaught AMQPTimeoutException) was totally my own mistake. I forgot to use PhpAmqpLib\Exception\AMQPTimeoutException; at the top of my file :(