> With this approach you accept that for some period of time your
> application may serve references with stale versions, thus client
> browsers may still use cached resources.
Don't you do the same when you use predicates like these? (taken from your code
sample below)
> new Or(new AccessedMoreThan(5), new OlderThan(30000)))));
In the worst case 5 clients will get the stale version before it gets updated
or any client within duration of 30000 (milliseconds?).
The basic idea behind resource caching (as the class name
IStaticCacheableResource indicates) is to cache static(!) resources which only
change during development.
For dynamic resources you should derive from AbstractResource and set the
caching headers accordingly.
I think it's not that common that people replace parts of the deployment during
runtime on the production server.
In projects I was involved the application always was rolled out as a whole at
certain points in time. Any change of the application usually needs to be
versioned, tested and carefully rolled out. If you need high availability you
should consider load balancing and redundant backend servers that can be taken
offline during re-deployment *imho*
So I think caching resources for the lifetime of an application totally makes
sense.
If you really need to replace files on the production server why not simply use
the same pattern as during development?
// use last-modified timestamp of packaged
resource for resource caching
// cache the version information for the
lifetime of the current http request
new RequestCycleCachedResourceVersion(new
LastModifiedResourceVersion());
The timestamp issues we mentioned for cluster deployment are not necessarily
existant in any case. If you have consistent timestamps across your backend
servers in the cluster last-modified based caching works like a charm.
I am -0 on the UpdatableCachingResourceVersion since I think it's too specific
to be part of core but I don't want to be a code nazi :-)
You use predicates for invalidation, somebody else wants a strategy pattern,
somebody else maybe wants listeners?!
I think the other wicket core devs should decide it.
Cheers
Peter
Am 12.11.2011 um 10:16 schrieb Dominik Drzewiecki:
> W dniu 11 listopada 2011 14:56 użytkownik Peter Ertl <[email protected]> napisał:
>> It might be a better idea to roll out your own version provider
>>
>> how do you check staleness?
> Well, you don't. You just recalculate the version (which requires some
> CPU/IO cycles, especially when using MessageDigest). The point is -
> with current implementations - you either need to recalculate the
> version on each resource link generation (which is bad in production
> environments) or you calculate it just once and cache it for
> application lifetime (which is much nicer for CPU and IO in producion,
> yet it leaves you unable to substitute resources without restart and
> be assured that customer's browsers use the most recent versions of
> your stylesheets or images rather than the cached ones.). That's why I
> proposed (and written) an UpdatableCachingResourceVersion which you
> should initialize with some rule specifying how often and/or after
> some period of time the getVersion() should be delegated to underlying
> implemention and returned version cached.
>
> With this approach you accept that for some period of time your
> application may serve references with stale versions, thus client
> browsers may still use cached resources.
>
> For applications that keep running unrestarted for weeks (one of major
> polish bank's ebanking application runs successfully on wicket, not
> 1.5 yet though), one can't accept caching versions for the application
> lifetime.
>
> And yes, you are right, it is easy and cheap to write my own
> implementation of IResourceVersion that just does that, but somehow I
> feel that this issue is not that specific to my particular use case
> and wanted to share to make wicket better.
>
> I hate to bloat the core and like to see it kept small and concise as
> it is now but I really think that UpdateableCachingResourceVersion
> belongs there.
>
> https://issues.apache.org/jira/browse/WICKET-4221
>
> regz,
> /dd
>
>>
>> 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 */
>>
>>
>
>
>
> --
> /* Spelin donut mader if iz ina coment */
