[
https://issues.apache.org/jira/browse/WICKET-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057368#comment-13057368
]
Peter Ertl commented on WICKET-3846:
------------------------------------
@igor: then we would have to choose between
(a) disabling caching for resources completely which will be _very_ bad for
performance
(b) use a short-lived caching period (like 1 hour) which will cause stale cache
entries when updating the deployed application
Basically we have to choose between broken behavior in some cluster
implementations and bad application upgrade behavior. Which pill do you want to
swallow? :-(
> in environments without reliable timestamps (e.g. some clusters) resource
> caching is useless
> --------------------------------------------------------------------------------------------
>
> Key: WICKET-3846
> URL: https://issues.apache.org/jira/browse/WICKET-3846
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC5.1
> Reporter: Peter Ertl
> Assignee: Peter Ertl
> Fix For: 1.5-RC6
>
> Attachments: cache.patch
>
>
> As mentioned already in the wicket userlist *iirc* wicket's default resource
> caching strategy using resource file timestamps will not work in some cluster
> environments. Cluster deployers seem to be quite dumb and not preserve the
> 'lastModified' file attribute. So depending on the server instance the
> resource is delivered from it will contain multiple timestamps for the same
> resource. Apparently timestamps seem to be unsuitable for the purpose of
> caching in that environment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
