Based on your description, would AMQPQueue::getMessage() not work for your needs? 
It is a non-blocking call and is very similar to the AMQPQueue::consume() method, 
callback excluded. If there is a good reason why you see the need for a timeout, I 
would like to hear it.

The imPlenentation we're currently using uses get in a while loop with sleep and a 
timeout. At high loads (~200 req/sec) we're seeing unexpectedly high CPU usage on 
the RabbitMQ server.

As get hits the server every time, and consume is a "push" mechanism, we'd like to 
see if performance is better with consume - but the timeout means we currently 
cannot.

Thanks for the quick response, I admit this request is based entirely on an 
assumption - however a timeout option in general gives much more control over 
failure conditions on a blocking call like this.

I will also appreciate that AMQPQueue::consume will timeout it's connection in defined time. Now it looks like consume blocks script execution until any message is received. It can take more time, than time_limit or default_socket_timeout, it looks like any of this options doesn't affect script execution.

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Unfortunately, there is nothing I can do. I rely on an underlying library called 
rabbitmq-c, which owns the execution scope when managing the socket connection tot 
he broker, something I cannot easily override or extend. Ill ask on the RabbitMQ 
mailing list to see if this is in the works.

Not a bug seems somewhat heavy handed!

As mentioned in the initial report, librabbitmq provides a method to peek at the 
buffer, which could be used to implement a timeout in the extension's code.

As comment #3 mentions, max_execution_time and default_socket_timeout are, as 
expected, ignored. However with no way to time-out this method is too dangerous to 
use in web code.

I'd appreciate if you could leave the bug open, and we'll try and pursue a fix at 
our end, either with a patch to this library, librabbitmq, or both.

Just a link related to this discussion which may help :
http://rabbitmq.1065348.n5.nabble.com/rabbitmq-c-Nonblocking-recv-td19912.html

I agree that we need an interrupt-driven (i.e. select(2)) solution for consume.  In a message queue, an important aspect is that we have a way to receive messages without wasting system resources on polling.  Currently, consume() calls amqp_simple_wait_frame, which is the same thing that get() does.  Essentially, consume() is just get() in a loop, which is probably redundant.

It looks like consume() should probably take a timeout value and call amqp_simple_wait_frame_noblock with that timeout.  The amqp_simple_wait_frame_noblock call does actually call select(2) with a timeout as you would expect in librabbitmq, for example.

I'll take a look at writing the patch myself, but since we all write out our grandiose plans on the Internet where they stay, abandoned for years, I thought I would at least leave this breadcrumb trail in case anyone else has the problem.  Hopefully I will write a follow-up shortly hereafter that includes a patch, but otherwise feel free to contact me if you have questions about the underlying stuff.