cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: Caching improvement ( from: Cocoon presentation link and questions about new contributions)
Date Fri, 12 Oct 2012 15:26:12 GMT
Hi Javier,

ok, that makes sense now. In what seem like the distant past we talked
about a bunch of things that could be done to the C2 caching systems. I
haven't ever dug into what has been done with C3 so I can't really guess at
how any of that would apply, but if I was starting from scratch I'd be
giving some consideration to event driven cache invalidation and maybe even
using memcached.

Peter Hunsberger

On Fri, Oct 12, 2012 at 6:58 AM, Javier Puerto <> wrote:

> Hi Peter,
> I've open a new thread as Thorsten did because I opened too many things in
> a single mail. :)
> 2012/10/11 Peter Hunsberger <>
>> Hi Javier,
>> not quite sure what you are asking about?  I know you're asking about
>> caching implementations, but it's not clear what the problem is in general
>> that you are addressing, or is this just a solution for a very specific
>> problem?  Is this caching Cocoon resources, HTTP level caching or maybe
>> even something in between?
> There's no problems in Apache Cocoon 3.0 caching system. It's working OK
> but I think that it could be better. With old cocoon releases, the caching
> system relies on the now discontinued framework Apache Excalibur [1].
> Cocoon 3.0 was rewritten to remove dependencies for these frameworks. Now,
> it has something similar now but it's lacks support for fragment caching
> [2] [3]. If a pipeline has a component that is not cacheable, the whole
> pipeline will be processed. With fragment caching all the components
> results are cached so the pipeline will start the execution with the first
> non-cacheable component. This can be minimized splitting big pipelines into
> smaller ones but sometimes is not desirable.
> When Francesco and I worked making the XIncludeTransformer and
> IncludeTransformer cacheable respectively, we found that we had to create
> something similar to old caching style. So I wonder if we can put some
> effort to migrate the old caching system, see discussion in [4].
> At end we need to add Javadoc to the current caching interfaces [5].
> Salu2
> [1]
> [2]
> [3]
> [4]
> [5]
>> Peter Hunsberger
>> On Wed, Oct 10, 2012 at 5:38 PM, Javier Puerto <> wrote:
>>> Hi all,
>>> I had working for an introduction talk about cocoon and I want lo leave
>>> the github link. The presentation is in Spanish because was for the
>>> and
>>> Comes with examples made with cocoon 3.0 parsing a F1 sport webpage and
>>> serve the contents in different formats. If you are interested I can
>>> translate the presentation to English (examples and code are in English).
>>> Link:
>>> Working on the presentation I did a proof of concept creating an Apache
>>> Tika generator. It's working but needs to enable caching and add the proper
>>> test cases and samples. If you are interested, I can finish it and commit
>>> changes.
>>> While I was working with cocoon at work time I started a
>>> OptimizerTransformer but I've found that IncludeTransformer is not
>>> cacheable so I worked first to get it cacheable (COCOON3-100)
>>> The transformer development is just at the beginning but before I
>>> continue to work with it I want your opinion. The idea is to use YUI
>>> compressor (BSD license) and define a custom language to define the static
>>> resources as CSS and JS. The transformer should review the resources,
>>> respect the order, compress the files and create optimized resources in a
>>> given path (to serve from Apache HTTPD with mod_cache and different
>>> domain). As this operation has a high cost, the transformer must control if
>>> the resource files changed. Finally, the transformer will place the proper
>>> tag with the URL for optimized static resources.
>>> WDYT? maybe there's better solutions (I know google HTTPD mod_pagespeed
>>> but it's always in beta state). The advantage is that you don't need to
>>> define everything at build time, with maven plugin for example so you can
>>> organize your static resources like you want (no one big file for all). On
>>> the other hand it has a high processor cost, but caching should minimize it.
>>> I didn't had time to work in Apache Cocoon 3.0 caching system since a
>>> couple of months ago. Recently, I had to switch the project and ATM I'm not
>>> working directly with cocoon. I want to take a closer look to the caching
>>> system when I can get some free time (COCOON3-30 and fragment caching),
>>> probably at December. Anyway, I will try to help in the mailing list and
>>> make some contributions like described above.
>>> I hope to see you soon in the ApacheCon,
>>> Salu2.

View raw message