[#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@horde.org
Requester jan@horde.org
Created 2013-03-04 (2690 days ago)
Due
Updated 2013-03-16 (2678 days ago)
Assigned 2013-03-04 (2690 days ago)
Resolved 2013-03-16 (2678 days ago)
Milestone
Patch No

Comments
Jan Schneider <jan@horde.org> 2013-03-04 12:54:34
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.

Michael Slusarz <slusarz@horde.org> 2013-03-04 20:40:30
> 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.

Jan Schneider <jan@horde.org> 2013-03-04 21:12:17
I had some reproducable fatal errors when I switched from no 
compression to lz4. I will check later to get the full error message.

Michael Slusarz <slusarz@horde.org> 2013-03-04 21:15:46
> 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.

Michael Slusarz <slusarz@horde.org> 2013-03-05 01:02:28
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).

Michael Slusarz <slusarz@horde.org> 2013-03-06 01:41:36
> 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.

Git Commit <commits@lists.horde.org> 2013-03-06 02:11:47
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

Michael Slusarz <slusarz@horde.org> 2013-03-16 15:48:26
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.