On Fri, Nov 11, 2011 at 1:46 PM, Peter Ertl <[email protected]> wrote: > We could add... > > CachingResourceVersion#invalidateResource(IResourceVersion) > > adding methods is api-compatible, right?
Adding methods to interfaces which the user might implement is not because she will have to implement this new method to fix her build. Just run: mvn clirr:check and it will tell you if there is something wrong. > > 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 > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
