You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Dominik Drzewiecki <do...@gmail.com> on 2011/11/10 23:46:55 UTC
Yet another IResourceVersion implementation
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())));
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).
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)))));
If you find it worth putting into core, I can file a jira issue and
provide an appropriate patch.
regz,
/dd
--
/* Spelin donut mader if iz ina coment */
Re: Yet another IResourceVersion implementation
Posted by Peter Ertl <pe...@gmx.org>.
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 <mg...@apache.org>:
>> Hi,
>>
>> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
>> <do...@gmail.com> 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 */
Re: Yet another IResourceVersion implementation
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Hi,
Couldn't this solved in a simpler manner by implementing a trigger to
clear the resource cache on demand? This way, you get full performance
in production and when you need to update a resource, log-in to an
administrative interface or JMX or something else and trigger the reload.
Regards,
Bertrand
On 12/11/2011 8:52 AM, Peter Ertl wrote:
>> 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<pe...@gmx.org> 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<mg...@apache.org>:
>>>>> Hi,
>>>>>
>>>>> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
>>>>> <do...@gmail.com> 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 */
>
Re: Yet another IResourceVersion implementation
Posted by Peter Ertl <pe...@gmx.org>.
> 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 <pe...@gmx.org> 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 <mg...@apache.org>:
>>>> Hi,
>>>>
>>>> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
>>>> <do...@gmail.com> 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 */
Re: Yet another IResourceVersion implementation
Posted by Dominik Drzewiecki <do...@gmail.com>.
W dniu 11 listopada 2011 14:56 użytkownik Peter Ertl <pe...@gmx.org> 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 <mg...@apache.org>:
>>> Hi,
>>>
>>> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
>>> <do...@gmail.com> 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 */
Re: Yet another IResourceVersion implementation
Posted by Peter Ertl <pe...@gmx.org>.
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 <mg...@apache.org>:
>> Hi,
>>
>> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
>> <do...@gmail.com> 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 */
Re: Yet another IResourceVersion implementation
Posted by Dominik Drzewiecki <do...@gmail.com>.
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 <mg...@apache.org>:
> Hi,
>
> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
> <do...@gmail.com> 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 */
Re: Yet another IResourceVersion implementation
Posted by Peter Ertl <pe...@gmx.net>.
done!
see https://issues.apache.org/jira/browse/WICKET-4218
Am 11.11.2011 um 13:24 schrieb Martin Grigorov:
> I agree :-)
>
> On Fri, Nov 11, 2011 at 2:20 PM, Peter Ertl <pe...@gmx.net> wrote:
>> CachingResourceVersion is not an interface but a concrete, non-final class so adding a method should be valid afaik
>>
>> Do you agree?
>>
>> Am 11.11.2011 um 13:16 schrieb Martin Grigorov:
>>
>>> On Fri, Nov 11, 2011 at 1:46 PM, Peter Ertl <pe...@gmx.org> 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
>>>>> <do...@gmail.com> 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
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
Re: Yet another IResourceVersion implementation
Posted by Martin Grigorov <mg...@apache.org>.
I agree :-)
On Fri, Nov 11, 2011 at 2:20 PM, Peter Ertl <pe...@gmx.net> wrote:
> CachingResourceVersion is not an interface but a concrete, non-final class so adding a method should be valid afaik
>
> Do you agree?
>
> Am 11.11.2011 um 13:16 schrieb Martin Grigorov:
>
>> On Fri, Nov 11, 2011 at 1:46 PM, Peter Ertl <pe...@gmx.org> 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
>>>> <do...@gmail.com> 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
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Yet another IResourceVersion implementation
Posted by Peter Ertl <pe...@gmx.net>.
CachingResourceVersion is not an interface but a concrete, non-final class so adding a method should be valid afaik
Do you agree?
Am 11.11.2011 um 13:16 schrieb Martin Grigorov:
> On Fri, Nov 11, 2011 at 1:46 PM, Peter Ertl <pe...@gmx.org> 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
>>> <do...@gmail.com> 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
Re: Yet another IResourceVersion implementation
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Nov 11, 2011 at 1:46 PM, Peter Ertl <pe...@gmx.org> 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
>> <do...@gmail.com> 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
Re: Yet another IResourceVersion implementation
Posted by Peter Ertl <pe...@gmx.org>.
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
> <do...@gmail.com> 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
Re: Yet another IResourceVersion implementation
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki
<do...@gmail.com> 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