<p>1. I think Zend_Queue_Message_Iterator is a typo of Zend_Queue_Adapter_Array, or vise verse. Could you please also provide skeleton of this class?</p>

<p>2. For method Zend_Queue_Message::setFromArray(), probably the input array should be stored in $this->_data.</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
public function setFromArray(array $data)
{
foreach ($data as $columnName => $value)

return $this;
}]]></ac:plain-text-body></ac:macro>

<p>Very nice proposal. Thanks.</p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
<p>The Zend Framework team approves this proposal for immediate development in the<br />
standard incubator, with the following requirements/suggestions:</p>
<ul>
<li>Check if queue adapters should have additional abstraction level for queues with transactions support.</li>
<li>Add method (or option) for retrieving message from queue as atomic operation. It may be important for some cases (e.g. taking jobs from queue by several executors).</li>
<li>Check if offered API conforms common messaging models (including models with message recieving notifications).</li>
</ul>
</ac:rich-text-body></ac:macro>

<p>Hi,</p>

<p>I'm very interested in your proposal, since we implemented a basic Queue Service ourselves using a DB as a backend. If we unify the development it would be better. We may need a STOMP or AMQP Backend for our next iteration, we would provide that.</p>

<p>I think it is very important that all backend adapters be concurrency-safe. E.g. if 5 clients are requesting the next message from the queue, the Adapter needs to make sure each message is returned only once. We do this by</p>

<p>$sQuery = 'UPDATE '.Hitmeister_Db_Tables::get('system_messages').<br />
' SET '.$this->aDbFields<ac:link><ri:page ri:content-title="'status_message'" /></ac:link>.' = \'READ\''.<br />
' WHERE '.$this->aDbFields<ac:link><ri:page ri:content-title="'id_message'" /></ac:link>.' = '.$oMessage->id_message.<br />
' AND '.$this->aDbFields<ac:link><ri:page ri:content-title="'status_message'" /></ac:link>.' = \'NEW\'';</p>

<p>//-- execute the statement<br />
$oStatement = $this->oDBH->prepare($sQuery);<br />
$oStatement->execute();<br />
if(!$oStatement)<br />

<br />
//-- check if was not able to update<br />
if ($oStatement->rowCount() == 0)<br />
{ try

<br />
catch (Exception $e)<br />

<br />
}<br />
This is more efficient than locking the table, at least in our use scenario.</p>

<p>One more thing we found: if you reduce the strict FIFO requirement to "more or less FIFO" you can get more performance out of the components. Perhaps make it variable in the next version?</p>

<p>What needs to be done for this proposal to move ahead. It seems to have been very little movement since august.</p>

<p>I think a component named that unspecific should be as unspecific as it's name is. How would you integrate Apache ActiveMQ or Rabbit MQ? Message Queues are Queues as well.</p>

<p>I'm currently working on a library for the Stomp protocol using various Message Queues which I designed with maximum flexibility in mind. You might want to take a look at how many parts are exchangeable in such a system (and that's Stomp specific!):</p>

<p><a class="external-link" href="http://github.com/felixjendrusch/stomp/tree/master/">http://github.com/felixjendrusch/stomp/tree/master/</a></p>

<p>I'm still writing the documentation because I had to get it working as fast as possible for a customer, sorry for that. Some components are not finished yet but it's working.</p>

<p>I started creating a queue using Zend_Queue_Db and have come across an issue. It appears that the send and receive methods of Zend_Queue_Db expect the active queue to be set by queue_id instead of name. </p>

<p>Zend_Queue_Db::create() will set the active queue by ID, so send and receive will work in that case. But, when using setActiveQueue() by name like in UC-01, send and receive will both fail because it is trying to set the queue_id to the queue name. </p>

<p>Is this the expected behavior or is it an issue with Zend_Queue_Db?</p>

<p>I still do not feel very confident with the name of this component. Zend_Queue is to general for this... what about message queues (Apache ActiveMQ, RabbitMQ, ...)? Will they get their own component (Zend_MessageQueue?)?</p>

<p>Hi Justin,</p>

<p>Can you rename setMsgClass(), setMsgsetClass(), and so on to setMessageClass() and setMessageSetClass()? Randomly abbreviating words like that can make an API difficult to remember.</p>

<p>I would also suggest that Stomp receive first-level support as Zend_Stomp (this is the case with other protocols, such as HTTP, Wildfire, etc.). Zend_Queue_Adapter_ActiveMQ and Zend_Queue_Adapter_RabbitMQ can then use that component. Perhaps the frame delimiter could be configurable via a method in Zend_Stomp, and ActiveMQ and RabbitMQ classes could simply set up the delimiter and then proxy requests to Zend_Stomp.</p>

<p>Is there any support for filtering based on certain criteria? This is a very common use case.</p>

<p>Otherwise, looking forward to seeing this in trunk!</p>

<p>-Matt</p>

<p>Are you planing to implement "gearman" ?<br />
It's an upcomming job system, which is easy to use and not bound to any language (you can add jobs to the queue from php, and get them from java).</p>

<p><a class="external-link" href="http://www.danga.com/gearman/">http://www.danga.com/gearman/</a>
<a class="external-link" href="http://www.gearman.org/doku.php">http://www.gearman.org/doku.php</a></p>

<p>I'd also like to see support for the SplQueue and SplPriorityQueue classes being added to the SPL in PHP 5.3. <ac:emoticon ac:name="smile" /></p>