Hi,
We are using Tiles 2.1.4 in a Servlet environment and using the
ResolvingLocaleUrlDefinitionDAO to load Tiles definition XML files and cache
them in memory. We have the need to hot deploy / refresh Tile definition XML
changes, and therefore call to refresh() on the URlDefinitionsFactory after
pushing out Tile definition XML changes. This in turn calls refresh() on our
definitionDao. It all works fine, except in the case described below where
refresh() /sometimes/ does not pick up the definition changes. Thoughts on
whether we are misconfigured or if this a bug in the framework are
appreciated...
My understanding of how request locales are handled:
Tiles stores an in-memory cache of Tile definition sets keyed by locale. These
definitions are built lazily as requests come in, based on the locale of the
request. If the locale on the request doesn't yet have definitions associated
with it, definitions are built for that locale (and parent locales) on-the-fly
and cached.
My understanding of how refresh() is managed:
A global data structure caches last modified dates for the Tile definition XML
files. Whenever the definitions are read from files, the last modified dates
are updated. Upon refresh, these cached last modified dates are compared to
the actual last modified date of each XML file on the file system to determine
if a refresh is needed.
The problem:
The lazy loading of definition sets per request locale contaminates the global
cache of last modified dates in the following situation:
* Updated Tile definition XML files are pushed onto servers. The servers
continue to field requests.
* A request with a previously unseen locale comes in, causing a set of
definitions to be built for that locale and parent locales. The updated XMLs
are processed from the file system for the new locale only, which updates the
global cache of XML file last modified dates.
* We call refresh(), which compares file system last modified dates to the
cached ones and only rebuilds if they differ. Since the global cache of last
modified dates was updated in the previous step, the framework doesn't detect
that anything has changed. It still holds out-dated definitions for all
locales other than new ones that come in after the XML file push. Some locales
are now out of sync, and refresh does not bring them current since it is a
no-op based on the updated last mod date cache.
The notion of refresh() relying on a global cache of last mod dates that can be
updated when only a single locale is processed appears to be an issue. Bug or
misuse?
Thanks!
- Jeff Reichenberg
