6.0.0-git
2019-05-19

[#12088] Need to clear or check cache if compression changes
Summary Need to clear or check cache if compression changes
Queue Horde Framework Packages
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester jan (at) horde (dot) org
Created 2013-03-04 (2267 days ago)
Due
Updated 2013-03-16 (2255 days ago)
Assigned 2013-03-04 (2267 days ago)
Resolved 2013-03-16 (2255 days ago)
Milestone
Patch No

History
2013-03-16 15:48:26 Michael Slusarz Comment #8
State ⇒ Resolved
Reply to this comment
Closing as resolved.  If this was an issue, there was a fix associated 
with this ticket that would have likely solved it.  And nobody has 
shown that invalid cached data (e.g. switching compression) will not 
be correctly invalidated.
2013-03-06 02:11:47 Git Commit Comment #7 Reply to this comment
Changes have been made in Git (master):

commit dc062d88fa534e968fe260d3bfe8032205f5b6d8
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Mar 5 18:22:05 2013 -0700

     [mms] Fix regression preventing compression of Horde_Cache data 
(Bug #12088).

  framework/Cache/lib/Horde/Cache.php |    6 +-----
  framework/Cache/package.xml         |    4 ++--
  2 files changed, 3 insertions(+), 7 deletions(-)

http://git.horde.org/horde-git/-/commit/dc062d88fa534e968fe260d3bfe8032205f5b6d8
2013-03-06 01:41:36 Michael Slusarz Comment #6 Reply to this comment
1) I just transitioned from LZ4->LZF->None->LZ4 (separate logins for 
each) and saw no warnings (even in debug logs).
D'oh.  Turns out that I essentially wrote the 'compress' parameter in 
Horde_Cache out of the class.  So this could have possibly left things 
in an inconsistent state (also why I would not see any difference 
moving through the various compressions strategies).

I'm releasing Horde_Cache 2.0.3 with this fix.  Cycling through the 
compression strategies without clearing the cache, I don't run into 
any issues.
2013-03-05 01:02:28 Michael Slusarz Comment #5 Reply to this comment
1) I just transitioned from LZ4->LZF->None->LZ4 (separate logins for 
each) and saw no warnings (even in debug logs).
2) What you are asking for is impossible anyway. There is no 
requirement that a Horde cache backend allows you to expire all keys 
(see, e.g., memcache).
2013-03-04 21:15:46 Michael Slusarz Comment #4 Reply to this comment
I had some reproducable fatal errors when I switched from no 
compression to lz4. I will check later to get the full error message.
If that is happening then obviously it needs to be fixed.

But any invalid cache data should never cause any problems because, by 
definition, cache must never be counted on as being available.
2013-03-04 21:12:17 Jan Schneider Comment #3 Reply to this comment
I had some reproducable fatal errors when I switched from no 
compression to lz4. I will check later to get the full error message.
2013-03-04 20:40:30 Michael Slusarz Comment #2
State ⇒ Feedback
Priority ⇒ 1. Low
Reply to this comment
Once horde_lz4 is stable, or even earlier when user have 
preferred_state=beta set, upgrading with -a will install the 
extension (even though not activating it by default). This will 
break existing caches though
No it won't.  In fact, I have not once cleared my cache that was 
previously stored with lzf compression and everything works fine.

I specifically made sure that horde_lzf fails gracefully if it tries 
to decompress non-lz4 compressed data.  In this case, it returns false 
which counts as a cache-miss.  Which is no big deal and something we 
do all the time (e.g. changing the serialize format of an object).

Sure - if someone upgrades when active sessions are active that 
session will likely be terminated.  But so what?  That could be said 
about any number of changes that would break active sessions.  We've 
never supported in-place upgrading of active sessions.
2013-03-04 12:54:51 Jan Schneider Priority ⇒ 2. Medium
 
2013-03-04 12:54:34 Jan Schneider Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 1. Low
Summary ⇒ Need to clear or check cache if compression changes
Queue ⇒ Horde Framework Packages
Assigned to Michael Slusarz
Milestone ⇒
Patch ⇒ No
Reply to this comment
Once horde_lz4 is stable, or even earlier when user have 
preferred_state=beta set, upgrading with -a will install the extension 
(even though not activating it by default). This will break existing 
caches though, probably as would installing/uninstalling lzf. We need 
to handle this more gracefully, because this might happen without 
explicit user interaction. A suggestion to run horde-clear-cache in 
INSTALL or UPGRADING wouldn't suffice.

Saved Queries