velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain (JIRA)" <>
Subject [jira] Commented: (VELTOOLS-59) WebappLoader's isSourceModified() and getLastModified() sometimes fail
Date Wed, 21 Jun 2006 21:48:30 GMT
    [ ] 

Will Glass-Husain commented on VELTOOLS-59:

Nice catch!

Nathan - your suggestion makes sense.

I'm a little worried about the race condition issue.  Maybe we should put some kind of block
in there until template initialization is complete?

> WebappLoader's isSourceModified() and getLastModified() sometimes fail
> ----------------------------------------------------------------------
>          Key: VELTOOLS-59
>          URL:
>      Project: VelocityTools
>         Type: Bug

>   Components: VelocityView
>     Versions: 1.1, 1.2, 1.3, 2.0
>  Environment: WebSphere v5.1.x on Linux and Win32, possibly other appservers or versions
of WebSphere as well.
>     Reporter: Stu Belden
>     Assignee: Nathan Bubna
>     Priority: Minor
>      Fix For: 1.3, 2.0

> The class ensures that all the paths
it can load from end with the '/' character.  When loading a template from disk in getResourceStream(),
WebappLoader ensures that the file to be loaded does not start with a '/' character, so the
file always loads properly.
> However, in isSourceModified(Resource resource) and getLastModified(Resource resource),
the same sanity check is _not_ made on the path of the resource, so you can have a path like
/myApp//some/file.vm.  The result of this, in my environment(s) at least, is that the isSourceModified()
check always returns true because the file cannot be found.  With caching turned on, this
leaves you with with the Least Efficient Cache Ever, since it always re-reads any template
requested after the modificationCheckInterval.
> I haven't looked at it carefully, but I think FileResourceLoader may have the same behavior.
> An interesting side effect of this unruly behavior is, I think, a race-condition bug
in the Template class.  In the process() method, the first thing it does is set its "data"
member, the AST of the template, to null.  However, another thread can get that same data
member while it's uninitialized.   This leads to the "java.lang.Exception: Template.merge()
failure. The document is null, most likely due to parsing error." error.  A google search
for "Template.merge() failure" turns up a couple web applications that, I think, are falling
prey to this problem as well.  This problem is easy to duplicate:
> 1. Enable resource loader caching
> 2. Set the modificationCheckInterval to something small, like 10 seconds.
> 3. Hammer your application with requests.
> I'm not intimately familiar with the internals of velocity, so I'm not sure what the
fix should be, or even where it should go.  FWIW, I ended up writing my own ResourceLoader
that expects a leading '/' on all template names. Thoughts?

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message