Issue Type: Bug Created: 2011-03-11T02:00:06.000+0000 Last Updated: 2011-03-11T02:47:21.000+0000 Status: Open Fix version(s): Reporter: Christiaan Kras (htbaa) Assignee: Justin Plock (jplock) Tags: - Zend_Queue
Related issues: Attachments:
-Zend_Queue_Adapter_Db doesn't implement the message timeout which will cause a message to be handled by multiple workers when requested. In line 346 this is mentioned as a TODO, but I think keeping this out causes a critical bug.-
Zend_Queue_Adapter_Db::receive() seems to be ignoring the default timeout that was set when creating a queue. Instead it uses Zend_Queue_Adapter_AdapterAbstract::RECEIVE_TIMEOUT_DEFAULT as its default. Knowning this it's easy enough for me to solve the problem I've got described below. I suggest this behavior gets changed so it uses the default of the queue, and not RECEIVE_TIMEOUT_DEFAULT.
Example: Every 5 minutes a worker script is being fired. In total it selects 100 messages to process. Timeout is set to 1 hour. When after 5 minutes the same worker script is being called whilst the first one isn't finished it'll happily steal the messages from the other worker since the timeout in reality is once set to a couple of seconds. At this time the original worker is still processing its initial message list. The second worker however is also processing the messages worker 1 is working on.
For non critical tasks this probably wouldn't cause much trouble (e.g. cache refreshing, generating static files). But when used for creating and sending an invoice and billing a customer this would cause the customer to get the invoice 2. This is just one example of what could go wrong and will go wrong when depending on the timeout. Which additionally also isn't documented...
...And more confusion on my side. I expected the given timeout to receive() would actually update the timeout field in the database to current timestamp + timeout. Instead, it only saves the current timestamp to it. Meaning that some other client is still able to receive the message when calling receive() with a timeout that differs (i.e. is lower) from the timeout used by the other client. This can't be intentional, can it?
Posted by Christiaan Kras (htbaa) on 2011-03-11T02:35:15.000+0000
Misdiagnosed the problem area
Have you found an issue?
See the Overview section for more details.