Caching suggestions

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Caching suggestions

greeneyed
Hi there "tocayo" ,
First of all, congrats on the work done. It already looks quite solid for a 1.0 release and so far the choices made sound very sensible.

I just developed the first prototype to integrate Thymeleaf into WebLEAF( project documentation is all down due to java.net migration to Kenai and my laziness to set it up all again in a different format ). In any case, I was able to get it up and running and test it in the WebLEAFTest demo (http://www.greeneyed.org/test/) and access data generated from Java/Groovy/JRuby... What I did was wrap the XML generated from those languages using dom4j and then use OGNL syntax to process the dom4j document. A bit verbose ATM but it works :D.

Now regarding the caching suggestions...

.- It is not mentioned anywhere and I'm not familiar enough with the code yet to find it out for myself but, have you considered (or are you using) the cache using soft references? Not critical but it helps sometimes when memory is a bit scarce and you don't want the cache to help causing an OOM ;).

.- Would it be possible to add a method to the template/resource resolvers so they ignore the cache TTL and reload the item (refreshing the cache) through a parameter? I find this feature pretty useful when I have to update a template/resource in an application when caching is enabled but I can say "in this request ignore the TTL and refresh templates/resources". Maybe adding an optional parameter like... TemplateEngine.process(String templateName, IContext context, boolean refresh)?


That's all... for now ;)
Cheers!
Daniel Lopez(greeneyed)
Reply | Threaded
Open this post in threaded view
|

Re: Caching suggestions

danielfernandez
Administrator
Hi Daniel,

greeneyed wrote
.- It is not mentioned anywhere and I'm not familiar enough with the code yet to find it out for myself but, have you considered (or are you using) the cache using soft references? Not critical but it helps sometimes when memory is a bit scarce and you don't want the cache to help causing an OOM ;).

To be honest, yes, I considered it, but only some time ago when I first implemented the cache in a very different shape to what it is today, and in that first implementation it actually made no sense at all...

...but now it is quite different, and I suppose I could give it a second thought, you are right. Maybe for next versions. If you want to keep track on this topic, you can add a Feature Request at the trackers...


greeneyed wrote
.- Would it be possible to add a method to the template/resource resolvers so they ignore the cache TTL and reload the item (refreshing the cache) through a parameter? I find this feature pretty useful when I have to update a template/resource in an application when caching is enabled but I can say "in this request ignore the TTL and refresh templates/resources". Maybe adding an optional parameter like... TemplateEngine.process(String templateName, IContext context, boolean refresh)?
Yes and no. It doesn't work exactly as you describe, but this will probably suit your needs with some tweaking: ITemplateResolver's "resolveTemplate(...)" method returns a TemplateResolution object, and this TemplateResolution object includes an attribute called "validity" implementing the "ITemplateResolutionValidity" interface.

This "validity" object will be asked two questions by the engine after template resolution takes place: 1st, whether the resolved template is to be considered cacheable or not ("isCacheable()", called only once before putting the template into the cache), and 2nd, whether the (already cached) template can be still considered "valid" ("isCacheStillValid()", called every time this template is retrieved from the cache).

The out-of-the-box implementations of the ITemplateResolver interface return an implementation of ITemplateResolutionValidity that simply bases this "validity" on the age of the cache entry, comparing it with a TTL. But you can create your own implementations of ITemplateResolutionValidity (which you could return from your own implementation of ITemplateResolver, for example subclassing AbstractTemplateResolver). And in this validity implementation of yours you could take the actions you consider adequate for determining whether the cached template can be used or rather a new template resolution operation must take place (which is what would happen if the cache entry is considered "invalid").

It's been a dense explanation, I hope you understand this last point...

Regards,
Daniel.
Reply | Threaded
Open this post in threaded view
|

Re: Caching suggestions

danielfernandez
Administrator
In reply to this post by greeneyed

FYI, a new snapshot of the future 1.0.1 version has been just uploaded to the Sonatype OSS Snapshots repository (http://oss.sonatype.org/content/repositories/snapshots/) with a SoftReference-based implementation of the parsed template cache.

If you wanted to test it, you should configure the snapshot repository and use version "1.0.1-SNAPSHOT" in your pom.xml.

Regards,
Daniel.
al
Reply | Threaded
Open this post in threaded view
|

Re: Caching suggestions

al
This post was updated on .
I think cool idea will be refactor caching and allow to configure choosing implementation of cache to use - default native  (yours , so no extra dependencies needed) or ehcache / which is common used library like in spring/hibernate/ or any other.
Reply | Threaded
Open this post in threaded view
|

Re: Caching suggestions

greeneyed
In reply to this post by danielfernandez
I saw how you added SoftReferences to the cache, thanks, and that's how I usually add them, so it should work fine. However, I found an interesting article* from a guy that followed the recommendations from the guys that made the java.lang package and the final solution was a bit more sophisticated, cleaning the soft references as soon as they are collected etc.
In this case, given that the number of soft references that could be GC-ed would be low, I don't think it is necessary to go that far, but I mention it here just out of curiosity and in case you want to get sophisticated ;).

About the possibility of allowing external caching implementations... I'm not sure it would be worth creating a plugin system to share the processed templates... what would be the benefit of storing the processed template in EHCache instead of internally?

* http://www.javaspecialists.eu/archive/Issue098.html

PD: I'll check the ITemplateResolutionValidity solution that you proposed for the other suggestion. I just started my holidays so I've been scubadiving instead of coding :D
Reply | Threaded
Open this post in threaded view
|

Re: Caching suggestions

danielfernandez
Administrator
@al

To be honest, I don't really see how to apply ehcache's regions to thymeleaf's parsed template cache. In fact, thymeleaf's cache infrastructure requirements are tiny compared to what ehcache provides, and I fear we'd probably be over-architecting here a bit. But of course I'd love to hear your ideas about how such generalization would be done, and which you think would be the benefits... If you're interested, please file a Feature Request at the trackers for this.


@greeneyed

Thanks for the link, very interesting. From this other link it seems that the HotSpot JVM changes its behaviour regarding SoftReferences depending on whether it is started in "client" or "server" mode. In client mode it will eat all of its soft references before growing the heap, and in server mode it will grow the heap before eating any soft references... which seems quite a sensible approach.

And.. scuba diving? lucky you! in NW Spain right now we could scuba dive in the streets if we wanted... it's been raining every single day of July! (yeah, tourists, not all Spain is sun and beach, it might come as a surprise for you... ;-)).

Regards,
Daniel.