[ 
http://issues.apache.org/jira/browse/VELTOOLS-59?page=comments#action_12417201 
] 

Marc Novakowski commented on VELTOOLS-59:
-----------------------------------------

While load testing our application, I think I ran into the race condition 
mentioned above.  The entries in the log file looked something like this:

ERROR Exception rendering #parse( /include/leaderboard.vm ) : 
java.lang.NullPointerException
ERROR Exception rendering #parse( /detail/album_layout.vm ) : 
java.lang.NullPointerException

and sometimes:

ERROR  Template.merge() failure. The document is null, most likely due to 
parsing error.
ERROR  VelocityViewServlet: Exception processing the template: 
java.lang.Exception: Template.merge() failure. The document is null, most 
likely due to parsing error.

We fixed it by turning off the "modificationCheckInterval" (which had been set 
to 4, it is now set to 0).  This workaround is adequate for us, since we don't 
modify template files on-the-fly in production.  But it would be nice to know 
that the underlying bug is fixed at some point!

In order to replicate this race condition, I had to put a lot of simulated load 
on the server.  I used a tool called "siege" with the following arguments:

siege -t 1H -i -b -c 100 -f urllist.txt

With approximately 300-400 hits per second against a dual-core machine, we saw 
error messages in the log at least every few seconds.

> WebappLoader's isSourceModified() and getLastModified() sometimes fail
> ----------------------------------------------------------------------
>
>          Key: VELTOOLS-59
>          URL: http://issues.apache.org/jira/browse/VELTOOLS-59
>      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 org.apache.velocity.tools.view.servlet.WebappLoader 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to