Many thanks,
find . -exec file {} \; |grep -i "PDF Document" worked a treat in
finding the PDF's in cache root.
I'll provide an example of Good vs Broken cached header files on
bugzilla hopefully this will assist in resolving the problem, however
I'm getting a fair of heat to resolve the issue so I think I might try
rolling back to Apache 1.3 as this uses mod_proxy to cache not
mod_cache/mod_disk_cache.
Thank you very much for all your help and advice,
Mark.
On 11/07/07, Vincent Bray <noodlet@xxxxxxxxx> wrote:
On 11/07/07, Mark Stevens <mark.stevens99@xxxxxxxxxxxxxx> wrote:
> Thanks Vincent,
>
> I took a look at the Change log under the trunk link you provided, and
> didn't see any specific fix on mod_cache for storing corrupted files
> however I did notice a mod_disk_cache fix that prevents it from
> storing responses from aborted requests..
>
> mod_disk_cache: Do not store aborted content. PR 21492.
>
> I'm wondering if this same fix could apply to the problem we are
> seeing, although I suspect this might already be implemented in 2.2.4.
>
>
> > There's a request for clarifications at the end of that bug. I'm sure
> > it'd be a big help if you could answer them.
>
> Yes I saw request for responses, but was unsure on how to locate where
> a specific cached item is located on disk, also the problem is pretty
> hard to replicate, the items seem to just turn up in the cache
> randomly.
Make sure you're logging everything. If possible, you could also leave
tcodump/tcpflow running on that socket, but I imagine that would fill
up your disk pretty quick.
> I had only seen that reported bug recently, I'll be happy to post my
> setup if it could provide any help.
>
> Can anyone advise how to locate an item that is cached on disk?
I'd make sure LogLevel debug is set, it might give some indication of
which path is being used for the cached response? If not, try running
something like
find /path/to/cache/root -exec file {} \; |grep -i pdf
though I have no idea if mod_disk_cache stores whole responses in such
a way that this would work. If it doesn't, I guess you could try
grepping for a chunk of binary data from the (broken) response.
Yes, it's a pain to track down these kinds of issues, but imagine what
it's like for the developers if they can't replicate the issue.
> Also would you not think running the trunk version in live environment
> slightly risky?
Yes, of course, especially as 2.3 is very early in its development
still. The point of testing trunk would be to see if there's some
change that should be backported to 2.2 :-)
--
noodl
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|