[Tickets #6410] lots of 'duplicate entry' when Horde_Cache is enabled

bugs at horde.org bugs at horde.org
Sun Mar 9 00:48:24 UTC 2008


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/6410
-----------------------------------------------------------------------
 Ticket             | 6410
 Created By         | leolistas at solutti.com.br
 Summary            | lots of 'duplicate entry' when Horde_Cache is enabled
 Queue              | Horde Base
 Version            | 3.2-RC2
 Type               | Bug
 State              | Unconfirmed
 Priority           | 1. Low
 Milestone          | 
 Patch              | 
 Owners             | 
-----------------------------------------------------------------------


leolistas at solutti.com.br (2008-03-08 19:48) wrote:

I have just downloaded Horde 3.2-RC2 and IMP 4.2-RC2 and get them working,
everything seems fine.

Then i created horde_cache table and enabled Horde_Cache with SQL-based
storage. Values are:
cache.default_lifetime: 86400
cache.driver: SQL-based storage
cache.params.driverconfig: Horde defaults
cache.params.table: horde_cache
cache.params.use_memorycache: none

after i enabled some cache using on IMP, just like:

Server Tab
server.cachejs: true
server.cachejsparams.timeout: 86400
server.cachejsparams.mtime: NOT checked
server.cachecss: true
server.cachecssparams.timeout: 86400
server.cachecssparams.mtime: NOT checked

Mailbox and Fetchmail Tab
use_mboxcache: Yes
mboxcache.use_compress: No
mboxcache.preview_size: 1000
mboxcache.lifetime: 259200
use_mlistcache: Yes
mlistcache.lifetime: 604800


After these changes, Horde/IMP appears to be working fine, there's no
error on the browser, everything seems to be working just fine. But on
logs, i got a REAL LOT of error messages on horde_cache tables.

I got a few SELECT errors, which seems to have an empty cache_id
parameter, just like:


Mar  8 21:42:01 f8 horde[25265]: [imp] DB Error: mismatch: SELECT
cache_id, cache_timestamp FROM horde_cache WHERE cache_id =   [DB Error:
mismatch] [pid 25265 on line 243 of
"/home/httpd/html/horde/lib/Horde/Cache/sql.php"]

Mar  8 21:42:01 f8 horde[25265]: [imp] DB Error: mismatch: SELECT
cache_id, cache_timestamp FROM horde_cache WHERE cache_id =   [DB Error:
mismatch] [pid 25265 on line 243 of
"/home/httpd/html/horde/lib/Horde/Cache/sql.php"]


and after those SELECT errors, i usually got a REAL LOT of INSERT errors:

Mar  8 21:41:11 f8 horde[25269]: [imp] DB Error: constraint violation:
INSERT INTO horde_cache (cache_id, cache_timestamp, cache_data) VALUES
('e629f174ffe682593097290b886eaae2', 1205023271, 0) [nativecode=1062 **
Duplicate entry 'e629f174ffe682593097290b886eaae2' for key 1] [pid 25269 on
line 198 of "/home/httpd/html/horde/lib/Horde/Cache/sql.php"]

Mar  8 21:41:11 f8 horde[25269]: [imp] DB Error: constraint violation:
INSERT INTO horde_cache (cache_id, cache_timestamp, cache_data) VALUES
('9f1846117c7ec45bb5c0cd5f8f4e8f51', 1205023271, 0) [nativecode=1062 **
Duplicate entry '9f1846117c7ec45bb5c0cd5f8f4e8f51' for key 1] [pid 25269 on
line 198 of "/home/httpd/html/horde/lib/Horde/Cache/sql.php"]

Mar  8 21:41:11 f8 horde[25269]: [imp] DB Error: constraint violation:
INSERT INTO horde_cache (cache_id, cache_timestamp, cache_data) VALUES
('4f921cb30288fa042067d6498244c86c', 1205023271, 0) [nativecode=1062 **
Duplicate entry '4f921cb30288fa042067d6498244c86c' for key 1] [pid 25269 on
line 198 of "/home/httpd/html/horde/lib/Horde/Cache/sql.php"]

Mar  8 21:41:11 f8 horde[25269]: [imp] DB Error: constraint violation:
INSERT INTO horde_cache (cache_id, cache_timestamp, cache_data) VALUES
('1b663801ffa1e296fcaf1be03d74957e', 1205023271, 0) [nativecode=1062 **
Duplicate entry '1b663801ffa1e296fcaf1be03d74957e' for key 1] [pid 25269 on
line 198 of "/home/httpd/html/horde/lib/Horde/Cache/sql.php"]


As I was using this horde/imp for testing somethings, i imagined, somehow,
i could have screwed up some table data, so i logout, cleaned ALL tables,
log the very first time with an user ... and there were the same errors
described above. So, it wasn't being caused by some screwed data on some
table.





More information about the bugs mailing list