We could add... CachingResourceVersion#invalidateResource(IResourceVersion)
adding methods is api-compatible, right? Cheers Peter Am 11.11.2011 um 09:09 schrieb Martin Grigorov: > 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
