You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2007/01/29 07:38:44 UTC

Re: FW: HTTPD mod_cache HttpCacheAction: where is 304?

On 1/28/07, Fuad Efendi <fu...@efendi.ca> wrote:
> Following to
> http://wiki.apache.org/cocoon/ControllingModCache
>
> I found this class:  org.apache.cocoon.acting.HttpCacheAction (dated
> 2004-07-29)
>
> Unfortunately, this action can't reply with 304 on request with HTTP Header
> [If-Modified-Since: ......]....

The idea is that the httpd front-end would handle that case: if a page
has been cached by the httpd front-end, conditional GETs will not hit
Cocoon until the httpd cache expires.

So yes, you could say that there's no caching between httpd and Cocoon
in this case. But this doesn't prevent you from using Cocoon's
internal caches in pipelines, if you need to.

-Bertrand

RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?

Posted by Fuad Efendi <fu...@efendi.ca>.
Server is slightly overloaded (80% CPU average, Robot is crawling Internet,
addind >50000 of new products daily), but HTTPD works fine...
www.tokenizer.org
please do not reload it;)
I'll check it from behind-corporate-proxy today.
Also I need to test that cache is not shared (still...) between workers in
v.2.2 of HTTPD... Memory of HTTPD Cache is not enough for milions of pages
generated by Cocoon.
Thanks


RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?

Posted by Fuad Efendi <fu...@efendi.ca>.
Sometimes (only sometimes!) HTTPD forwards requests "If-Modified-Since" from
Internet Explorer to Cocoon. Without 304 we will never have cache!

When I say "sometimes" I mean that few different caches exists at HTTPD,
per-process. We may have 32 processes, 128 threads each, total: 32 caches
with memory limitations. That was true with previous v.2.0.44 and
experimental mod_cache. If HTTPD does not have cached page (due to LRU), it
will forward to Cocoon with "If-Modified-Since" (which originally came from
Internet Explorer, or from another corporate proxy). Cocoon must reply with
304.

Additionally, existing HttpCacheAction create new Expiration header for each
request. So that 32 caches at HTTPD will be out-of-sync (same page, but
different expiration).

All this is from my old experience, I tested it 4 years ago with WebLogic 7
and Apache HTTPD 2.0.44... It works now with some very small amount of
additional code, very attractive (thanks to Cocoon!)


Thanks,
Fuad.


-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org] 
Sent: Monday, January 29, 2007 1:39 AM
To: dev@cocoon.apache.org
Subject: Re: FW: HTTPD mod_cache HttpCacheAction: where is 304?


On 1/28/07, Fuad Efendi <fu...@efendi.ca> wrote:
> Following to
> http://wiki.apache.org/cocoon/ControllingModCache
>
> I found this class:  org.apache.cocoon.acting.HttpCacheAction (dated
> 2004-07-29)
>
> Unfortunately, this action can't reply with 304 on request with HTTP
Header
> [If-Modified-Since: ......]....

The idea is that the httpd front-end would handle that case: if a page
has been cached by the httpd front-end, conditional GETs will not hit
Cocoon until the httpd cache expires.

So yes, you could say that there's no caching between httpd and Cocoon
in this case. But this doesn't prevent you from using Cocoon's
internal caches in pipelines, if you need to.

-Bertrand