Issue Type: Bug Created: 2011-02-08T02:52:51.000+0000 Last Updated: 2012-12-18T20:08:27.000+0000 Status: Resolved Fix version(s): - 1.12.1 (18/Dec/12)
Reporter: Valentine Mayamsin (wargoth) Assignee: Justin Plock (jplock) Tags: - Zend_Queue
Related issues: Attachments:
There is wrong type chosen for "timestamp" as "real". It represents timestamp as 1.29716e+09 which is quite coarse and often leads to duplicate messages. The solution is to choose "double precision" or "bigint" with refactoring to integer value insted of float microtime.
I attach a patch which fixes Postgres schema
<pre class="highlight">Index: Zend/Queue/Adapter/Db/postgresql.sql =================================================================== --- Zend/Queue/Adapter/Db/postgresql.sql (revision 13905) +++ Zend/Queue/Adapter/Db/postgresql.sql (working copy) @@ -38,7 +38,7 @@ handle character(32), body character varying(8192) NOT NULL, md5 character(32) NOT NULL, - timeout real, + timeout double precision, created integer, CONSTRAINT message_pk PRIMARY KEY (message_id), CONSTRAINT message_ibfk_1 FOREIGN KEY (queue_id)
Posted by Adam Lundrigan (adamlundrigan) on 2011-12-01T12:07:37.000+0000
This issue still exists in trunk. Can the maintainer of Zend_Queue, or someone else familiar with it's operation, please comment on the suggested fix? Are there any BC-break issues with changing the schema?
Posted by Mike Willbanks (digitalstruct) on 2012-01-26T04:26:31.000+0000
While this might fix the schema; unfortunately this issue would then exist in other schemas. The patch itself on this one would work appropriately; specifically speaking this mainly is only utilized when receiving messages (see Zend/Queue/Adapter/AdapterAbstract.php). Update during this method will store the microtime (result of microtime(true)) in which case he is correct. However, this should not lead to duplicate messages.
Posted by Rob Allen (rob) on 2012-11-03T14:16:52.000+0000
Fixed in trunk (25064) and release-1.12.1 (25065)
Have you found an issue?
See the Overview section for more details.