Since there is not much limbo dance happening with the synchronized instance of HashMap in CachingResourceVersion the usage of Collections#synchronizedMap() is not unscalable per default *imho*.
We probably could optimize the evil 'synchronized' away by using more sophisticated locking but I doubt it will in any significant way boost an app's performance in regular cases. :-) For specific cases like your the framework should be extensible enough so you can easily extend / delegate / implement your own resource caching behavior. 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 */
