You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Javier Puerto <ja...@apache.org> on 2012/03/05 14:50:01 UTC
CachingServletServiceSerializer
Hello Cocoon developers,
We are using Apache Cocoon 2.2 for a project and I've found a bottleneck in
our template system. We use servlet service components to render our pages
in the same way you can see for Style Block. The current Cocoon Welcome
block is an example.
This way of rendering is very useful but as currently the servlet services
components doesn't implement CacheableServiceComponent interface, all the
request will be processed completely at the end.
For our usecase, here is an example:
<map:match pattern="x">
<map:generate ...
<map:transform ...
<map:include ...
<map:serialize type="servletService">
<map:parameter name="service"
value="servlet:style:/service/common/simple-page2html"/>
</map:serialize>
</map:match>
The most expensive part is the serialization process because we use i18n,
Link rewriter and some transformations. We can configure everything to be
cacheable but at the end, the serialization process must be performed
entirely. I've simply extended the current ServletServiceSerializer in
CachingServletServiceSerializer adding the cache key as requested service
URL and NOPValidity as validity object. This approach has a problem, due to
the nature of the servlet service components we need to move all the
dynamically generated content from our GUI block since if we detect that
the content hasn't changed, the CachingServletServiceSerializer will not
perform any process and will return the cached content. Also, as there's a
little hack for serializer output mime type, if you want to use the new
component you must set the serialization content type explicitly. See
http://article.gmane.org/gmane.text.xml.cocoon.devel/73261
<map:match pattern="x">
<map:generate ...
<map:transform ...
<map:include ...
<map:serialize type="caching-servletService" mime-type="text/html">
<map:parameter name="service"
value="servlet:style:/service/common/simple-page2html"/>
</map:serialize>
</map:match>
For our usecase seems to fit well and will allow us to enable the powerful
cocoon caching system for a lot of pages. IMO, it's a problem when you want
to use the ServletServiceSerializer to have a clean and common output for
the template system and you can't use the caching even with static files.
Attached is the patch for cocoon-servlet-service-components block.
Salu2.
Re: CachingServletServiceSerializer
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 05/03/2012 16:03, Javier Puerto wrote:
> Hi Francesco
>
> 2012/3/5 Francesco Chicchiriccò <ilgrosso@apache.org
> <ma...@apache.org>>
>
> Hi Javier,
> from a very first look your approach seems very interesting: could you
> please file an issue on JIRA and attach your patch there? Thanks.
>
>
> Done. You can found the patch and description here:
> https://issues.apache.org/jira/browse/COCOON-2320
Thanks!
>
>
> I might b wrong, but it seems to me that Cocoon 3.0 could also benefit
> entirely from your patch.
>
>
> Yeah, I think so because I think that C3 is using the same base code
> for SSF. But unfortunately I don't have time atm to work with C3, only
> some quick looks.
If this is fine for all, I'd like to take this issue in order to review
and apply Javier's patch.
However, I think it would be the case to take the chance to do a general
"refresh" and update of SSF, waiting for planned SVN refactoring [1] to
take place.
I'll have enough time to reserve to Cocoon in a more or less one month:
if anyone else is available before I won't get offended :-)
Regards.
[1]
http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--tt32880500.html
--
Francesco Chicchiriccò
Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
Re: CachingServletServiceSerializer
Posted by Javier Puerto <ja...@apache.org>.
Hi Francesco
2012/3/5 Francesco Chicchiriccò <il...@apache.org>
> Hi Javier,
> from a very first look your approach seems very interesting: could you
> please file an issue on JIRA and attach your patch there? Thanks.
>
Done. You can found the patch and description here:
https://issues.apache.org/jira/browse/COCOON-2320
>
> I might b wrong, but it seems to me that Cocoon 3.0 could also benefit
> entirely from your patch.
>
Yeah, I think so because I think that C3 is using the same base code for
SSF. But unfortunately I don't have time atm to work with C3, only some
quick looks.
>
> Regards.
>
Salu2.
>
> On 05/03/2012 14:50, Javier Puerto wrote:
> > Hello Cocoon developers,
> >
> > We are using Apache Cocoon 2.2 for a project and I've found a
> > bottleneck in our template system. We use servlet service components
> > to render our pages in the same way you can see for Style Block. The
> > current Cocoon Welcome block is an example.
> >
> > This way of rendering is very useful but as currently the servlet
> > services components doesn't implement CacheableServiceComponent
> > interface, all the request will be processed completely at the end.
> >
> > For our usecase, here is an example:
> >
> > <map:match pattern="x">
> > <map:generate ...
> > <map:transform ...
> > <map:include ...
> > <map:serialize type="servletService">
> > <map:parameter name="service"
> > value="servlet:style:/service/common/simple-page2html"/>
> > </map:serialize>
> > </map:match>
> >
> > The most expensive part is the serialization process because we use
> > i18n, Link rewriter and some transformations. We can configure
> > everything to be cacheable but at the end, the serialization process
> > must be performed entirely. I've simply extended the current
> > ServletServiceSerializer in CachingServletServiceSerializer adding the
> > cache key as requested service URL and NOPValidity as validity object.
> > This approach has a problem, due to the nature of the servlet service
> > components we need to move all the dynamically generated content from
> > our GUI block since if we detect that the content hasn't changed, the
> > CachingServletServiceSerializer will not perform any process and will
> > return the cached content. Also, as there's a little hack for
> > serializer output mime type, if you want to use the new component you
> > must set the serialization content type explicitly. See
> > http://article.gmane.org/gmane.text.xml.cocoon.devel/73261
> >
> > <map:match pattern="x">
> > <map:generate ...
> > <map:transform ...
> > <map:include ...
> > <map:serialize type="caching-servletService" mime-type="text/html">
> > <map:parameter name="service"
> > value="servlet:style:/service/common/simple-page2html"/>
> > </map:serialize>
> > </map:match>
> >
> > For our usecase seems to fit well and will allow us to enable the
> > powerful cocoon caching system for a lot of pages. IMO, it's a problem
> > when you want to use the ServletServiceSerializer to have a clean and
> > common output for the template system and you can't use the caching
> > even with static files.
> >
> > Attached is the patch for cocoon-servlet-service-components block.
> >
> > Salu2.
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>
>
Re: CachingServletServiceSerializer
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi Javier,
from a very first look your approach seems very interesting: could you
please file an issue on JIRA and attach your patch there? Thanks.
I might b wrong, but it seems to me that Cocoon 3.0 could also benefit
entirely from your patch.
Regards.
On 05/03/2012 14:50, Javier Puerto wrote:
> Hello Cocoon developers,
>
> We are using Apache Cocoon 2.2 for a project and I've found a
> bottleneck in our template system. We use servlet service components
> to render our pages in the same way you can see for Style Block. The
> current Cocoon Welcome block is an example.
>
> This way of rendering is very useful but as currently the servlet
> services components doesn't implement CacheableServiceComponent
> interface, all the request will be processed completely at the end.
>
> For our usecase, here is an example:
>
> <map:match pattern="x">
> <map:generate ...
> <map:transform ...
> <map:include ...
> <map:serialize type="servletService">
> <map:parameter name="service"
> value="servlet:style:/service/common/simple-page2html"/>
> </map:serialize>
> </map:match>
>
> The most expensive part is the serialization process because we use
> i18n, Link rewriter and some transformations. We can configure
> everything to be cacheable but at the end, the serialization process
> must be performed entirely. I've simply extended the current
> ServletServiceSerializer in CachingServletServiceSerializer adding the
> cache key as requested service URL and NOPValidity as validity object.
> This approach has a problem, due to the nature of the servlet service
> components we need to move all the dynamically generated content from
> our GUI block since if we detect that the content hasn't changed, the
> CachingServletServiceSerializer will not perform any process and will
> return the cached content. Also, as there's a little hack for
> serializer output mime type, if you want to use the new component you
> must set the serialization content type explicitly. See
> http://article.gmane.org/gmane.text.xml.cocoon.devel/73261
>
> <map:match pattern="x">
> <map:generate ...
> <map:transform ...
> <map:include ...
> <map:serialize type="caching-servletService" mime-type="text/html">
> <map:parameter name="service"
> value="servlet:style:/service/common/simple-page2html"/>
> </map:serialize>
> </map:match>
>
> For our usecase seems to fit well and will allow us to enable the
> powerful cocoon caching system for a lot of pages. IMO, it's a problem
> when you want to use the ServletServiceSerializer to have a clean and
> common output for the template system and you can't use the caching
> even with static files.
>
> Attached is the patch for cocoon-servlet-service-components block.
>
> Salu2.
--
Francesco Chicchiriccò
Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/