Fault-tolerant Resource Loader Cache?

[White, Tim]

Hi -
 
 I'm wondering if there are any settings I can apply to the Resource
Loader Cache in velocity, specifically the FileResourceLoader, that
would allow it to be 'fault tolerant'.
 
 By this, I mean if the file system that it's looking for its files in
goes away, gets corrupted, gets very slow, etc.  if it could use the
previously cached version of the resource, rather that loading is as
'not found'.
 
 The idea being that, if you load the resource successfully once, don't
replace it with a missing resource..instead, keep the previously,
successfully loaded copy.
 
 Keep checking to see if a new, working resource can be loaded, but
never load a resource as not found if you've already loaded it
successfully once.
 
  Obviously, this is a setting we'd only want to use in our production
environments.
 
Any thoughts?
 
Thanks,
 
Tim


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

[Nathan Bubna]

Would it not work for you to turn caching on and set the
modificationCheckInterval to 0?  Of course this would mean no changes
to template would be recognized (fault or otherwise).

If the goal is to allow templates to change, but not be
deleted/corrupted/whatever, then that seems rather tricky.  Even if we
created such a setting, you would presumably have to make your cache
large enough to fit all your templates so none of them were ever
cleared from memory.

Anyway, if the combo of caching and turning of modification checking
isn't sufficient, then the straight answer is no, there is no
"fault-tolerant cache" setting.  You could probably implement this by
creating a custom ResourceManager.  This would probably involve
subclassing org.apache.velocity.runtime.resource.ResourceManagerImpl
and overriding the refreshResource(...)  method to catch
ResourceNotFoundExceptions and ParseErrorExceptions or whatever other
faults you want to be tolerant of.  I've never tried this, but i
imagine it would be fairly straightfoward.

On Tue, Apr 29, 2008 at 6:33 AM, White, Tim <Tim.White@...> wrote:

> Hi -
>
>   I'm wondering if there are any settings I can apply to the Resource
>  Loader Cache in velocity, specifically the FileResourceLoader, that
>  would allow it to be 'fault tolerant'.
>
>   By this, I mean if the file system that it's looking for its files in
>  goes away, gets corrupted, gets very slow, etc.  if it could use the
>  previously cached version of the resource, rather that loading is as
>  'not found'.
>
>   The idea being that, if you load the resource successfully once, don't
>  replace it with a missing resource..instead, keep the previously,
>  successfully loaded copy.
>
>   Keep checking to see if a new, working resource can be loaded, but
>  never load a resource as not found if you've already loaded it
>  successfully once.
>
>   Obviously, this is a setting we'd only want to use in our production
>  environments.
>
>  Any thoughts?
>
>  Thanks,
>
>  Tim
>
>
>  This communication is the property of Qwest and may contain confidential or
>  privileged information. Unauthorized use of this communication is strictly
>  prohibited and may be unlawful.  If you have received this communication
>  in error, please immediately notify the sender by reply e-mail and destroy
>  all copies of the communication and any attachments.
>

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

[White, Tim]

> Would it not work for you to turn caching on and set the
modificationCheckInterval to 0?  Of course this would mean no
> changes to template would be recognized (fault or otherwise).

Unfortunately, we need them to be able to be changed after the server
has been started.

> Even if we created such a setting, you would presumably have to make
your cache large enough to fit all
> your templates so none of them were ever cleared from memory.

Yes.

> You could probably implement this by creating a custom
ResourceManager.

Right, that was what I was thinking...just a balance of risk between
hedging against our NFS failures, and future-proofing such code
extensions...

Thanks for the thoughts,

Tim


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

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

[Nathan Bubna]

On Tue, Apr 29, 2008 at 11:35 AM, White, Tim <Tim.White@...> wrote:

> > Would it not work for you to turn caching on and set the
>  modificationCheckInterval to 0?  Of course this would mean no
>  > changes to template would be recognized (fault or otherwise).
>
>  Unfortunately, we need them to be able to be changed after the server
>  has been started.
>
>
>  > Even if we created such a setting, you would presumably have to make
>  your cache large enough to fit all
>  > your templates so none of them were ever cleared from memory.
>
>  Yes.
>
>
>  > You could probably implement this by creating a custom
>  ResourceManager.
>
>  Right, that was what I was thinking...just a balance of risk between
>  hedging against our NFS failures, and future-proofing such code
>  extensions...

ResourceManager has not changed much over the years, if it helps to know that.

>  Thanks for the thoughts,
>
>
>  Tim
>
>
>  This communication is the property of Qwest and may contain confidential or
>  privileged information. Unauthorized use of this communication is strictly
>  prohibited and may be unlawful.  If you have received this communication
>  in error, please immediately notify the sender by reply e-mail and destroy
>  all copies of the communication and any attachments.
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: user-unsubscribe@...
>  For additional commands, e-mail: user-help@...
>
>

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