tiles-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Reichenberg <jreichenb...@hotwire.com>
Subject Locales and refresh()
Date Wed, 10 Mar 2010 20:57:26 GMT

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?


- Jeff Reichenberg

View raw message