Hi,

On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
<[email protected]> wrote:
> Howdy,
>
> I've been loooking carefully at what's new in wicket 1.5 and how its
> concepts map to the earlier versions.
> I've been particularly interested in how resource managment had been
> given much care in 1.5.
> One great feature is consistent resource id suffix generation. I have
> however found an issue that may lead to a performace hit.
>
> It is advised to use MessageDigestResourceVersion rather than the
> default LastModifiedResourceVersion in production environments,
> especially clustered ones. Thus the following code present in
> application init() method:
>
>                getResourceSettings().setCachingStrategy(
>                                new FilenameWithVersionResourceCachingStrategy(
>                                                new 
> MessageDigestResourceVersion()));
>
> This however is highly ineficient as each and every access to any
> resource (resource link generation, in fact) results in message digest
> computation, regardless whether it is going to be sent back to the
> browser or not. Lets wrap the MessageDigestResourceVersion with
> CachingResourceVersion then:
>
>                getResourceSettings().setCachingStrategy(
>                                new FilenameWithVersionResourceCachingStrategy(
>                                                new CachingResourceVersion(new 
> MessageDigestResourceVersion())));

This looks OK.

>
> Aha! Much better? Not exactly. Now the message digest will be computed
> just once, and will stay in a cache for the lifetime of the
> application. Whenever resource changes, the browser might be confused
> to use stale cached version rather than request a new resource (Yes,
> we do substitute context resources during runtime).

In production resources don't change that often. It is not that common
to substitute resources in production.

>
> It'd be nice to have some IResourceVersion implementation that caches
> the computed resource version for some preconfigured period of time or
> recalculates it on every n-th access. Or is triggeerd by some more
> complex rule.
>
>                getResourceSettings().setCachingStrategy(
>                                new FilenameWithVersionResourceCachingStrategy(
>                                                new 
> UpdateableCachingResourceVersion(new
> MessageDigestResourceVersion(), new Or(new AccessedMoreThan(5), new
> OlderThan(30000)))));

For your use case this will be the best but for the common case just
CachingResourceVersion should be enough, IMO.

>
> If you find it worth putting into core, I can file a jira issue and
> provide an appropriate patch.

Sure, do it!

>
> regz,
> /dd
>
> --
> /* Spelin donut mader if iz ina coment */
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Reply via email to