[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    Re: Velocity page caching problem
From:       Nathan Bubna <nbubna () gmail ! com>
Date:       2009-04-22 19:07:00
Message-ID: 4d651da50904221207i45263268r855240ee9cdc359f () mail ! gmail ! com
[Download RAW message or body]

On Wed, Apr 22, 2009 at 11:33 AM, Doug Carter <dcarter@mercycorps.org> wrote:
>
> Nathan,
>
>> velosurf.properties?  was that a typo?  looks like it's using
>> /WEB-INF/velocity.properties
>
> Typo.
>
>> anyway, it's difficult to guess what is happening, in part because
>> your description varies.  first, it takes a few "save out"s to get it
>> to refresh.  is that because of the time it takes to do the saves? or
>> the saves themselves?  then you first say setting
>> webapp.resource.loader.cache=false doesn't make a difference, then
>> next it "seems to help".  it would be good to have more precise
>> information.  if setting the w.r.l.c=false changes things, *how* does
>> it change things?  What are you seeing happen?
>
> I'm sorry about the lousy feedback and variable responses. I know how
> difficult it is to problem solve with crappy data. I've got several
> webapps running together on a dev server, trying to juggle too many
> problems at one time. This is not the way to fix it.
>
>> this is only log output for startup.  can i see logs for what happens
>> when you request a template, change it, then request it again? (or
>> some similar set of actions that shows the problem)
>
> I need to setup a dedicated debug environment for this, turn on some
> logging, etc. and remove all the unnecessary variables, so I stop wasting
> your time.
>
> This may not even be a Tomcat problem.
>
> First, I checked my disk cache in Firefox for a test page:
>
>  Last modified: 2009-04-22 11:20:14
>  Expires: 1969-12-31 16:00:00
>
> As a simple test, I modified the test page, setting "border=1" on a table,
> then saved it, and did a stat on the source file:
>
>  Access: 2009-04-22 11:21:35.000000000 -0700
>  Modify: 2009-04-22 11:21:35.000000000 -0700
>  Change: 2009-04-22 11:21:35.000000000 -0700
>
>
> So, the file is *newer* on server disk than the last modified cache date
> on the PC disk. I refresh the page, and the table border does not come
> on, meaning that the file was not read. If I check the Firefox cache,
> it shows:
>
>  Last modified: 2009-04-22 11:21:50
>  Expires: 1969-12-31 16:00:00
>
> So, I have to assume that something is caching this page within the
> server. But this is still all anecdotal.
>
> I'll setup a better test environment, with a standalone Tomcat instance
> and a single test page. The only thing I'm unsure of, is the level and
> type of logging. Is there something specific that can show cache info?
> I'd rather do a controlled experiment that can give you actionable data.

In a simplified test environment, it should be manageable to have the
log level set to debug.  And using log4j should give the most control.
 The ServletLogger is a bit noisy.

Also, if you are going to set up a test for this, as you describe,
then once you have reproduced the problem and tried what we've
discussed thus far, consider trying it again with Velocity 1.6.2
there have been a variety of fixes and improvements in the resource
management code (and in logging, for more useful output).

> Thanks again for your time,
>
> Doug
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]