cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <>
Subject RE: DO NOT REPLY [Bug 6879] - [PATCH] Cache improvement using ESI invalidation protocol
Date Wed, 24 Apr 2002 21:08:03 GMT
a short answer.
I send the reply to the Cocoon dev. List. I think the
topic is very interesting and need to be discussed with
a broader publicum. 
Let's discuss the topic there!


>  I apologize for the delay on the reply.
>  First, I am not offended.



>  Here the anwser of your questions:
>    1) I can't understand this point.

The current Caching process is something like this:

Cachable request ---> CachingxxxPipeline ---> lookup Store ---> Validate Object

When I understand everything right you do something like

                              Http Post Message
                          External Cache Invalidator 
                        Some Invalidator Server Thread                             
(Ignore current process ---->) Validate Object

So this is my current high level understandig of your approach.
_Please_ correct me, if I understand something wrong here. Draw a 
picture, that helps!

Ahem it's the "ignore current process" part, which I don't like ;-)...

Question: Why is it impossible for you to do it in the current Caching 

>    2) In my test case the background Thread do not impact in the 
>performance of Cocoon, that is, enabling or not the server through 
>cocoon.xconf file the average response time of cocoon components is the 
>same. One alternative is to leave the entry in cocoon.xconf commented 
>and the user that need the behaviour uncomment it.

Note: you're not the only thread in Cocoon. Every Thread has an direct impact 
on the Performance. Multithreading is very complex and I made the expierence
in Cocoon to implement Threads only when it is neccassary and for a
generic use (see Berins proposals about event queues...)

>    3) The logon in the invalidator xsp page uses standard http/https 
>protocol and is a regular XSP page, that is, the security warkaround 
>here is equal to any other xsp page. As an aditional security feature 
>its possible to check the IP number of the sender. (Username/password 
>and ip checking is the standard security filters implemented by Oracle 
>Web Cache and I don't know any security problem with this comercial 
>product). In the other hand this xsp page only parses an xml input 
>message and signals the Cache Server to invalidate pages.

Again, when implementing such a feature then IMO it must:
(a) fit in the current Cocoon pipeline process 
(b) and more generic, like a system wait security and authorization model
which supports different protocols...

>    4) This functionality bost the final performance of database 
>intensive calculation. For example in a tradicional portal page like My 
>Yahoo, the stocks quotes content is viewed by millions of user a day, if 
>this stock quotes are calculated, obviusly, by an sql query in a target 
>database, the XSP page that query this table never will be more quickly 
>than the cached xsp content that only call at the method "isValid" of 
>the ExternalCacheValidity object.
>    In this situation the control of the content is inverted, that is, 
>the origin of the sources signals at the cache instead of the provider 
>ask for a new content. As a final result instead of to sent a jdbc 
>message to the database for the content of the quotes in every page hit 
>only a few messages are sent by the database when the table is updated.
>   And thats all, if you have any other questions sent me an email,  I 
>would like to receive positive or negative comment.

This I believe and I can feel your pain. I think you ideas are valid but
IMHO they must fit better into the current Cocoon pipeline architecture.

But it would be interesting what other devs. think of it.

"Anything awful makes me laugh. 
I misbehaved once at a funeral..."

To unsubscribe, e-mail:
For additional commands, email:

View raw message