It might be a better idea to roll out your own version provider how do you check staleness?
take that criteria and make it part of the filename version if that check is cheap you don't need caching Am 11.11.2011 um 14:29 schrieb Dominik Drzewiecki: > I have a working implementation with passive (on access, rather than > active, requiring some reaper thread) resource staleness checking. > I'll file a jira issue today evening (CET) and attach a patch. BTW, > CachingResourceVersion is considerably non-scalable in terms of > concurrency as it uses Collections#synchronizedMap() underneath. > > 2011/11/11, Martin Grigorov <[email protected]>: >> 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 >> > > -- > Wysłane z mojego urządzenia przenośnego > > /* Spelin donut mader if iz ina coment */
