You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2012/08/23 17:28:43 UTC

[Bug 53767] New: htcacheclean deletes stale "vary" header files even if cache limits aren't reached

https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

          Priority: P2
            Bug ID: 53767
          Assignee: bugs@httpd.apache.org
           Summary: htcacheclean deletes stale "vary" header files even if
                    cache limits aren't reached
          Severity: normal
    Classification: Unclassified
                OS: Linux
          Reporter: andy.hutson+apache@gmail.com
          Hardware: PC
            Status: NEW
           Version: 2.2.21
         Component: mod_cache_disk / mod_disk_cache
           Product: Apache httpd-2

Created attachment 29268
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=29268&action=edit
strace output

For a resource that contains a "Vary" header, mod_cache creates a .header file
containing the "vary" headers, and then creates a subdirectory
(<hash>.header.vary), which in turn contains the actual .header and .data
files.

Assuming the cache is not above the limit specified by htcacheclean, stale
content should remain in place so that it can be while revalidating content or
if there's an error (ie CacheStaleOnError behaviour). For non-varying
resources, this works fine.

However, for resources that "vary", it appears there is a bug in htcacheclean.
Once the content is stale, it deletes the top level .header file (containing
the "vary" headers), even if the cache is within limits, meaning mod_cache is
unable to serve the stale content (htcacheclean reports "0 entries deleted"
though). It would appear that creating an empty .data file alongside the
.header file prevents this from happening.

I'm attaching the output of the following, for reference, which shows the
unlink call at line 173:
strace -o ~/strace.out -s 512 htcacheclean -r -v -p /data/httpcache/httpd/ -l
1000k

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 53767] htcacheclean deletes stale "vary" header files even if cache limits aren't reached

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

andyh <an...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|andy.hutson@gmail.com       |

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 53767] htcacheclean deletes stale "vary" header files even if cache limits aren't reached

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

--- Comment #1 from andyh <an...@gmail.com> ---
Incidentally, this happens with or without the "-r" switch.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 53767] htcacheclean deletes stale "vary" header files even if cache limits aren't reached

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

--- Comment #2 from andyh <an...@gmail.com> ---
>From http://svn.apache.org/repos/asf/httpd/httpd/trunk/support/htcacheclean.c
(which is later than the one we're running, but I believe has the same issue);
looks like this is the section that's doing it:

        /* single data and header files may be deleted either in realclean
         * mode or if their modification timestamp is not within a
         * specified positive or negative offset to the current time.
         * this handling is necessary due to possible race conditions
         * between apache and this process
         */
        case HEADER:
            current = apr_time_now();
            nextpath = apr_pstrcat(p, path, "/", d->basename,
                                   CACHE_HEADER_SUFFIX, NULL);
            if (apr_file_open(&fd, nextpath, APR_FOPEN_READ | APR_FOPEN_BINARY,
                              APR_OS_DEFAULT, p) == APR_SUCCESS) {
                len = sizeof(format);
                if (apr_file_read_full(fd, &format, len,
                                       &len) == APR_SUCCESS) {
                    if (format == VARY_FORMAT_VERSION) {
                        apr_time_t expires;

                        len = sizeof(expires);

                        if (apr_file_read_full(fd, &expires, len,
                                               &len) == APR_SUCCESS) {
                            apr_finfo_t finfo;

                            apr_file_close(fd);

                            if (apr_stat(&finfo, apr_pstrcat(p, nextpath,
                                    CACHE_VDIR_SUFFIX, NULL), APR_FINFO_TYPE,
p)
                                    || finfo.filetype != APR_DIR) {
                                delete_entry(path, d->basename, nodes, p);
                            }
                            else if (expires < current) {
                                delete_entry(path, d->basename, nodes, p);
                            }

                            break;
                        }
                    }


Specifically, this part:
                            else if (expires < current) {
                                delete_entry(path, d->basename, nodes, p);
                            }

This seems to be deleting expired vary header files by design. But this breaks
CacheStaleOnError handling, as well as (but to a lesser extent) the
stale-while-revalidate function that CacheLock provides, for any resources that
vary.

Not sure if there's any reason to be deleting these header files? They'll get
deleted later on anyway, in purge(), if the cache is above limits. If there's
no other need, should these three lines simply be removed?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 53767] htcacheclean deletes stale "vary" header files even if cache limits aren't reached

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

andyh <an...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andy.hutson@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 53767] htcacheclean deletes stale "vary" header files even if cache limits aren't reached

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

David Holroyd <da...@badgers-in-foil.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave@badgers-in-foil.co.uk

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 53767] htcacheclean deletes stale "vary" header files even if cache limits aren't reached

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53767

macbogucki@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andy.hutson+apache@gmail.co
                   |                            |m

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org