php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #61202 Support timeout on AMQPQueue::consume
Submitted: 2012-02-28 14:14 UTC Modified: 2012-11-19 12:06 UTC
From: glen dot mailer at bskyb dot com Assigned:
Status: Not a bug Package: amqp (PECL)
PHP Version: Irrelevant OS: Any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: glen dot mailer at bskyb dot com
New email:
PHP Version: OS:

 

 [2012-02-28 14:14 UTC] glen dot mailer at bskyb dot com
Description:
------------
The call to consume is blocking, but there's no way to tell the call to stop listening after a certain amount of time. The use-case for this is when implementing a remote RPC mechanism, we want to stop listening on the reply queue if we think the server is not going to publish a response.

An additional parameter for timeout would be excellent, I had a quick look at the implementation details, and it looks like amqp_data_in_buffer can be used to peek at the buffer before the blocking call to amqp_simple_wait_frame.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-28 23:52 UTC] pdezwart@php.net
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.
 [2012-02-29 07:31 UTC] glen dot mailer at bskyb dot com
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.
 [2012-02-29 17:41 UTC] php at shark dot kom dot cz
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.
 [2012-03-02 20:26 UTC] pdezwart@php.net
-Status: Open +Status: Not a bug
 [2012-03-02 20:26 UTC] pdezwart@php.net
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.
 [2012-03-05 08:29 UTC] glen dot mailer at bskyb dot com
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.
 [2012-11-19 12:06 UTC] jpauli@php.net
Just a link related to this discussion which may help :
http://rabbitmq.1065348.n5.nabble.com/rabbitmq-c-Nonblocking-recv-td19912.html
 [2013-10-30 03:36 UTC] bgeisel1 at gmail dot com
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.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Mon Nov 30 01:01:22 2020 UTC