You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2002/03/05 15:39:16 UTC

DO NOT REPLY [Bug 6879] New: - [patch] Cache improvement using ESI invalidation protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6879>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6879

[patch] Cache improvement using ESI invalidation protocol

           Summary: [patch] Cache improvement using ESI invalidation
                    protocol
           Product: Cocoon 2
           Version: 2.0.1
          Platform: All
               URL: http://www.dbprism.com.ar/dbprism/doc/xdocs/Server.html
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: general components
        AssignedTo: cocoon-dev@xml.apache.org
        ReportedBy: mochoa@ieee.org


Hi all:
 I have implemented and External Cache Invalidator object and server to
implement a synchorized way for invalidating Cocoon2's cached pages (from
outside) through an simple XSP page that interpret an HTTP post message.
 This solution is implemented by DB Prism Generator for Cocoon2 and is usefull
for making (using content agregation) news feeds "a la" My yahoo, this kind of
news feed are implemented selecting the news from a simple table inside the
database, this news are only invalidated when the database process an
update/insert or delete on the corrected table that fires a trigger which send
an http messages to the invalidator XSP page, this message
(http://www.w3.org/TR/esi-invp) includes information about the url arguments and
cookies used to indentified the page. When this message is processed by the
invalidator XSP page contact the invalidator server and enqueue the message.
 Cocoon will ask to the ExternalCacheValidity which implements the interface
CacheValidity for the validity of the page, this object contact the invalidator
server and return true or false depending on the response of the External
invalidator server.
 Here the class which implement the previous functionality:
    - org.apache.cocoon.components.cache.Server (Interface which is an Avalon
component and defines the functionality of External Invalidator Servers)
    - org.apache.cocoon.components.cache.InMemoryServerImpl (Concrete Class
which implements the previous one interface and provide an InMemory
implementation of the Invalidator container, this class uses a HashMap for
storing cached pages keys and a linked list for implementing the queue of
invalidation messages)
   - org.apache.cocoon.caching.ExternalCacheValidity ( implements
org.apache.cocoon.caching.CacheValidity and return true or false if the pages is
cached by the external invalidator server.
Note: Cached by the external invalidator server means that this page is not
stored by the server, the pages is stored in the Cocoon cache system, this
server only register an encoded url which identified the page and return true or
false if the page is valid.
 - An XSP page invalidte.xsp, which receives http post messages whith the pages
to be removed from the server.
Usabilty, DBPrismGenerator uses this technique interpreting an internal sitemap
argument named Cache-Control, here an example of this setting:
  <map:match pattern="header/**.xml">
   <map:generate type="dbprism" src="/cms/CMSj.header">
       <map:parameter name="Cache-Control" value="External"/>
       <map:parameter name="source" value="/{1}.xml"/>
       <map:parameter name="printable" value="no"/>
   </map:generate>
   <map:serialize/>
  </map:match>
 This means that the resource will be resolved by DBPrismGenerator
(type=dbprism) and this generator returns on the method generateValidity() an
object of type ExternalCacheValidity, here the code:
     ....
     } else if (this.cacheControl==Server.EXTERNAL) {
       if (getLogger().isDebugEnabled())
            getLogger().debug("generateValidity called returning
ExternalCacheValidity");
       return new
ExternalCacheValidity(this.generateKey(),this.cacheServer,this.encodedURL);
     ....
  This external cache validity objects is identified by a unique key (generated
by the CacheServer) and the encoded url, the encoded url is generated with the
syntax /path/object?arg1=val1&arg2=val&Coookie:name1=val1&Cookie:name2=val2,
this url is used then to ask for the availibilty of the page on the server or not.
  DBPrismGenerator uses this object but, its possible to use into an XSP page
too, see simple_ext.xsp as an example of an XSP page which is externally
invalidated.
  Here an example of the invalidation message sent by the database to Cocoon to
invalidate an specific page:

POST /cocoon/x-dbprism-cache-invalidate HTTP/1.0
Authorization: BASIC aW52YWxpZGF0b3I6aW52YWxpZGF0b3I=
Content-Length: 189

<?xml version="1.0"?>
<INVALIDATION VERSION="WCS-1.0">
<OBJECT>
<BASICSELECTOR URI="docs/samples/xsp/simple_ext.xsp"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

  Obviusly the External Cache Invalidator server use an username and password to
validate the request which arrive from outside Cocoon, this user/password is
encoded into http header Authorization in Base 64 form (in this case
invalidator/invalidator), this invalidation xml message means that the XSP will
invalidate the XSP demo page (docs/samples/xsp/simple_ext.xsp) with no 
arguments. REMOVALTTL=seconds is reserved for future use on the Cache Server if
it imlement and prioritized list of invalidation messages, this mean that
messages with different time-to-live will re-order in the invalidation queue.
  Here an example of an Oracle trigger which sends an invalidation message to
Cocoon when a user update a CMS page :
CREATE OR REPLACE TRIGGER TOPIC_INVALID_TRIG
  AFTER UPDATE on FAQ_TOPICS
   DECLARE
      par cache.cache_parameters;
   BEGIN

      par.num_vals := 1;
      par.names(1) := 'ext';
      par.vals(1) := 'html';
      cache.invalidate('webcachehost',8888,'/cms/','faq.doIt',par);
   END;
 It uses an stored procedure cache.invalidate which compose the xml post message
showed above.
 I attached the sources of the class and examples for more information.
 Best regards, Marcelo.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org