#012175: cache-block subtree_expiry never expires

It might be related to this one ?
http://issues.ez.no/IssueView.php?Id=11829&activeItem=4

#255039 by Xavier Dutoit on December 4th, 2007 [Permanent Link]

I can confirm that I have the same problem on 4.0

My code (pr user cache):

{cache-block expiry=3600 keys=array( $current_user.contentobject_id, $offset ) subtree_expiry=concat('content/view/full/', $node.node_id)}
..
{/cache-block}

And the cache is not expired when $node is republished or new nodes is added int $node's subtree, only when time expiry happens.

#255110 by André R. on December 11th, 2007 [Permanent Link]

Caused by the code coming from the cluster enhancement branch, merged to trunk in rev. 19175.

fixed in
stable/3.10 (3.10.1) rev. 21271
trunk (4.1.0alpha1) rev. 21272
stable/4.0 (4.0.1) rev. 21273

#255602 by Kristof Coomans on January 28th, 2008 [Permanent Link]

I've been testing this patch for couple of days now and it seems like subtree_expiry now works fine, but another functionality got messed-up, because ignore_content_expiry directive doesn't seem to work correctly. When I publish new content, the ignore_content_expiry doesn't save my site from jumping from 5-7 up to 150 MySQL queries for each key combination (for example, for each node). After that, it's all back to normal, but another publishing will again invalidate the cache.

I've tested it as thoroughly as I could, eliminating other possibilities. When I remove the patch, the site goes back to the clean 4.0.0 behavior - subtree_expiry stops to work while the ignore_content_expiry begins to take effect.

Please, make cache-block (and other cache layers, especially viewcache) fully functional for 4.0.1 because without that it's practically impossible to precisely optimize a site and all other functionality becomes useless... An earlier patch (or some feedback if I'm wrong) would be greatly appreciated.

PS. I filed this as a separate bug:
http://issues.ez.no/IssueView.php?Id=13016&activeItem=1

#256663 by Piotrek Karaś on May 12th, 2008 [Permanent Link]

Needs to be re-looked at due to comments of Piotrek.

#256669 by Kristof Coomans on May 13th, 2008 [Permanent Link]

Additional fixes in
trunk (4.1.0alpha1) rev. 21838
stable/4.0 (4.0.1) rev. 21839
stable/3.10 (3.10.1) rev. 21840

ignore_content_expiry was also broken in 4.0 with template compilation turned off.

Please let us know if there are still any issues occurring.

#256670 by Kristof Coomans on May 13th, 2008 [Permanent Link]

Yet another bug: when template compilation is disabled, using expiry=0 will always expire the cache block, while http://ez.no/doc/ez_publish/technical_manual/4_0/reference/template_functions/miscellaneous/cache_block says: "A value of zero will produce a cache block that will never expire."

#256671 by Kristof Coomans on May 13th, 2008 [Permanent Link]

Yes, I confirm the problem with expiry=0. However, it does seem to work with ignore_content_expiry flag on ;) Isn't that supposed to work this way? expiry=0 still means "never expire", but if used without ignore_content_expiry, it will be clear by random publish? This leaves all combinations available...

{cache-block expiry=0}
<div style="border:1px solid #ff0000; margin:3px; padding:2px;">
{currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}cache-block expiry=0{rdelim}
</div>
{/cache-block}

{cache-block ignore_content_expiry expiry=0}
<div style="border:1px solid #ff0000; margin:3px; padding:2px;">
{currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}ignore_content_expiry expiry=0{rdelim}
</div>
{/cache-block}

{cache-block expiry=60}
<div style="border:1px solid #ff0000; margin:3px; padding:2px;">
{currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}expiry=60{rdelim}
</div>
{/cache-block}

{cache-block ignore_content_expiry expiry=60}
<div style="border:1px solid #ff0000; margin:3px; padding:2px;">
{currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}ignore_content_expiry expiry=60{rdelim}
</div>
{/cache-block}

{cache-block subtree_expiry=59}
<div style="border:1px solid #ff0000; margin:3px; padding:2px;">
{currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}subtree_expiry=59{rdelim}
</div>
{/cache-block}

{cache-block subtree_expiry=59 expiry=60}
<div style="border:1px solid #ff0000; margin:3px; padding:2px;">
{currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}subtree_expiry=59 expiry=60{rdelim}
</div>
{/cache-block}

#256677 by Piotrek Karaś on May 13th, 2008 [Permanent Link]

Yes, I do understand that. It's just that by having it the way I described it two comments above (or the way it's been working since yesterday's patches), it would still be possible to have all required scenarios served, and even more:

If you use:

{cache-block ignore_content_expiry}

then the expiry parameter is still set to default value. So, it will expire after 2 hours. So, if you want indefinite block, you will have to decide explicitly:

{cache-block expiry=0}

but in such case, if you take ignore_content_expiry as set by default, you will not be able to form the following rule: keep my block as long as nothing new is published, even if it is 10 years! Currently (as of yesterday) you can. If you fix that, I will have to come up with some fictional big number, for example 31536000 for a year:

{cache-block expiry=31536000}

I understand that sentence in the documentation:
"A value of zero will produce a cache block that will never expire."
On the other hand, shouldn't that be interpreted in relation to other parameters? I would change that rule because it will a little bit more logical and also will not block the above combinations. But - that's just my opinion ;)

#256680 by Piotrek Karaś on May 14th, 2008 [Permanent Link]

"A value of zero will produce a cache block that will never expire" looks more like a documentation bug, I'm pretty sure it shouldn't automatically add ignore_content_expiry when 0.

It should work like Piotrek mentions {cache-block expiry=0} should expire if something is published, this way you can combine it with subtree_expiry or ignore_content_expiry as you wish.

#256681 by André R. on May 14th, 2008 [Permanent Link]

{cache-block expiry=0} should expire if something is published

If an object is published, all blocks will automatically be expired.

By default, all cache blocks will be expired whenever an object is published.

There still is something wrong with cache-blocks, though. We're just testing it with a production site, and we used a block like this:

{cache-block keys=array( $uri_string ) expiry=600 ignore_content_expiry}

But it fails to ignore content expiry! Now, we've tested this just moments ago and it seemed fine, so the only difference I can see is the fact that we used custom keys. Also, the problem stays until we add subtree_expiry:

{cache-block keys=array( $uri_string ) expiry=600 ignore_content_expiry subtree_expiry=12345}

The above code stops the block from getting expired upon random object publishing.
I'll give that some more thourough tests in a few minutes.

#256683 by Piotrek Karaś on May 14th, 2008 [Permanent Link]

Here's an example, just paste it into your pagelayout, generate once and quickly publish a random node, whose node_id!=59:

<table>
<tr><th>STANDARD</th><th>WITH KEYS</th></tr>
<tr><td>
    {cache-block expiry=0}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}cache-block expiry=0{rdelim}
    {/cache-block}
    </td><td>
    {cache-block expiry=0 keys=array( $uri_string )}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}cache-block expiry=0 keys=array( $uri_string ){rdelim}
    {/cache-block}
</td></tr><tr><td>
    {cache-block ignore_content_expiry expiry=0}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}ignore_content_expiry expiry=0{rdelim}
    {/cache-block}
    </td><td>
    {cache-block ignore_content_expiry expiry=0 keys=array( $uri_string )}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}ignore_content_expiry expiry=0 keys=array( $uri_string ){rdelim}
    {/cache-block}
</td></tr><tr><td>
    {cache-block expiry=60}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}expiry=60{rdelim}
    {/cache-block}
    </td><td>
    {cache-block expiry=60 keys=array( $uri_string )}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}expiry=60 keys=array( $uri_string ){rdelim}
    {/cache-block}
</td></tr><tr><td>
    {cache-block ignore_content_expiry expiry=60}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}ignore_content_expiry expiry=60{rdelim}
    {/cache-block}
    </td><td>
    {cache-block ignore_content_expiry expiry=60 keys=array( $uri_string )}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}ignore_content_expiry expiry=60 keys=array( $uri_string ){rdelim}
    {/cache-block}
</td></tr><tr><td>
    {cache-block subtree_expiry=59}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}subtree_expiry=59{rdelim}
    {/cache-block}
    </td><td>
    {cache-block subtree_expiry=59 keys=array( $uri_string )}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}subtree_expiry=59 keys=array( $uri_string ){rdelim}
    {/cache-block}
</td></tr><tr><td>
    {cache-block subtree_expiry=59 expiry=60}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}subtree_expiry=59 expiry=60{rdelim}
    {/cache-block}
    </td><td>
    {cache-block subtree_expiry=59 expiry=60 keys=array( $uri_string )}
    {currentdate()|datetime( 'custom', '%Y-%m-%d %H:%i:%s' )} {ldelim}subtree_expiry=59 expiry=60 keys=array( $uri_string ){rdelim}
    {/cache-block}
</td></tr></table>

Result: cache-blocks behave diffrently depending on whether they do have or do not have custom keys ;)

#256684 by Piotrek Karaś on May 14th, 2008 [Permanent Link]

I think that you have a bad apreciation, when you don´t use cache-keys, ez automatically create one based on the position and template name. If you repeat the same cache-keys throw diferents places, you can obtain the content of first processed block-cache for all this blocks.

It doesn't a issue.

#256741 by Bayron Guevara on May 20th, 2008 [Permanent Link]

Please analyze carefully my example (above) and what I wrote. Just like Kristof says, "when you use user-defined cache keys, the template and position of the cache block are still used as cache keys as well" - and that's what I understand, so I don't see how 2 separate cache blocks could get mixed up (if I got it correctly). But I think I was precise in my conclusion that "cache-blocks behave diffrently depending on whether they do have or do not have custom keys" and since user-defined keys are just additional keys, that sould not be a case.

#256749 by Piotrek Karaś on May 20th, 2008 [Permanent Link]

Additional fixes in
trunk (4.1.0alpha1) rev. 21868
stable/4.0 (4.0.1) rev. 21869
stable/3.10 (3.10.1) rev. 21870

I tried to test as many cases as possible and it seems to work as intended now. Please let me know if any unexpected behaviour still occurs.

#256753 by Kristof Coomans on May 20th, 2008 [Permanent Link]

Everything seems to be fine and consistent after my first tests. I'll put it on more realistic tests tonight ;) Thanks!

#256771 by Piotrek Karaś on May 20th, 2008 [Permanent Link]

Closing :)

#256792 by Kristof Coomans on May 21st, 2008 [Permanent Link]

I've put it on a production site - seems fine!

#256802 by Piotrek Karaś on May 22nd, 2008 [Permanent Link]