You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by dl...@apache.org on 2003/10/22 05:00:47 UTC
cvs commit: jakarta-velocity/src/java/org/apache/velocity/runtime RuntimeConstants.java
dlr 2003/10/21 20:00:47
Modified: docs developer-guide.html changes.html
xdocs developer-guide.xml changes.xml
src/java/org/apache/velocity/runtime/resource
ResourceCacheImpl.java
src/java/org/apache/velocity/runtime RuntimeConstants.java
Log:
* src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java
initialize(RuntimeServices): Leveraged LRUMap from Commons
Collections. If the resource.manager.cache.size property is set to
0 or less, the previous greedy behavior is available.
* src/java/org/apache/velocity/runtime/RuntimeConstants.java
RESOURCE_MANAGER_CACHE_CLASS: Added JavaDoc.
RESOURCE_MANAGER_CACHE_SIZE: New constant for the resource cache
size property.
* xdocs/developer-guide.xml
* docs/developer-guide.html
Mentioned the RESOURCE_MANAGER_CACHE_SIZE
(resource.manager.cache.size) property.
* xdocs/changes.xml
* docs/changes.html
Noted new LRUMap implementation of ResourceCacheImpl.
* TODO.txt
Removed the "Control Caching Resource Usage" item.
Revision Changes Path
1.103 +31 -0 jakarta-velocity/docs/developer-guide.html
Index: developer-guide.html
===================================================================
RCS file: /home/cvs/jakarta-velocity/docs/developer-guide.html,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -u -r1.102 -r1.103
--- developer-guide.html 21 Oct 2003 12:05:36 -0000 1.102
+++ developer-guide.html 22 Oct 2003 03:00:46 -0000 1.103
@@ -3195,6 +3195,37 @@
This key is also defined as a contstant
<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
</p>
+ <p>
+A resource cache implementation may want to limit the cache size
+(rather than providing an unbounded cache which could consume all
+available memory). To configure Velocity to set the size for your
+cache, use the configuration key:
+</p>
+ <div align="left">
+ <table cellspacing="4" cellpadding="0" border="0">
+ <tr>
+ <td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ <td bgcolor="#023264" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ <td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ </tr>
+ <tr>
+ <td bgcolor="#023264" width="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ <td bgcolor="#ffffff"><pre>
+resource.manager.cache.size
+</pre></td>
+ <td bgcolor="#023264" width="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ </tr>
+ <tr>
+ <td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ <td bgcolor="#023264" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ <td bgcolor="#023264" width="1" height="1"><img src="/images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"/></td>
+ </tr>
+ </table>
+ </div>
+ <p>
+This key is also defined as a contstant
+<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
+</p>
</blockquote>
</p>
</td></tr>
1.104 +10 -1 jakarta-velocity/docs/changes.html
Index: changes.html
===================================================================
RCS file: /home/cvs/jakarta-velocity/docs/changes.html,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -u -r1.103 -r1.104
--- changes.html 22 Oct 2003 02:04:01 -0000 1.103
+++ changes.html 22 Oct 2003 03:00:46 -0000 1.104
@@ -169,8 +169,17 @@
references, and Category.getInstance() with Logger.getLogger(). (#19133) (dlr)
</li>
<li>
-Decommissioned the long-deprecated Log4JLogSystem. Never fear,
+Removed the long-deprecated Log4JLogSystem. Never fear,
SimpleLog4JLogSystem remains. (dlr)
+</li>
+<li>
+Enhanced the implementation of ResourceCacheImpl using Jakarta Commons
+Collections LRUMap class. The previous greedy implementation did not
+set an upper bound for the cache size, meaning that cached resources
+were never relinquished (a possible memory leak). You can continue to
+use that behavior by setting the
+<code>resource.manager.cache.size</code> for your cache to less than
+1. (dlr)
</li>
</ul>
</blockquote>
1.70 +16 -0 jakarta-velocity/xdocs/developer-guide.xml
Index: developer-guide.xml
===================================================================
RCS file: /home/cvs/jakarta-velocity/xdocs/developer-guide.xml,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -u -r1.69 -r1.70
--- developer-guide.xml 27 Jan 2003 21:06:27 -0000 1.69
+++ developer-guide.xml 22 Oct 2003 03:00:46 -0000 1.70
@@ -2590,6 +2590,22 @@
<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
</p>
+<p>
+A resource cache implementation may want to limit the cache size
+(rather than providing an unbounded cache which could consume all
+available memory). To configure Velocity to set the size for your
+cache, use the configuration key:
+</p>
+
+<source><![CDATA[
+resource.manager.cache.size
+]]></source>
+
+<p>
+This key is also defined as a contstant
+<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
+</p>
+
</section>
<section name="Template Encoding for Internationalization">
1.96 +9 -0 jakarta-velocity/xdocs/changes.xml
Index: changes.xml
===================================================================
RCS file: /home/cvs/jakarta-velocity/xdocs/changes.xml,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -u -r1.95 -r1.96
--- changes.xml 22 Oct 2003 02:04:01 -0000 1.95
+++ changes.xml 22 Oct 2003 03:00:46 -0000 1.96
@@ -32,6 +32,15 @@
Removed the long-deprecated Log4JLogSystem. Never fear,
SimpleLog4JLogSystem remains. (dlr)
</li>
+<li>
+Enhanced the implementation of ResourceCacheImpl using Jakarta Commons
+Collections LRUMap class. The previous greedy implementation did not
+set an upper bound for the cache size, meaning that cached resources
+were never relinquished (a possible memory leak). You can continue to
+use that behavior by setting the
+<code>resource.manager.cache.size</code> for your cache to less than
+1. (dlr)
+</li>
</ul>
</subsection>
1.3 +24 -4 jakarta-velocity/src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java
Index: ResourceCacheImpl.java
===================================================================
RCS file: /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -u -r1.2 -r1.3
--- ResourceCacheImpl.java 12 Feb 2002 19:08:06 -0000 1.2
+++ ResourceCacheImpl.java 22 Oct 2003 03:00:46 -0000 1.3
@@ -54,14 +54,24 @@
* <http://www.apache.org/>.
*/
+import java.util.Collections;
import java.util.Hashtable;
import java.util.Map;
import java.util.Iterator;
+
+import org.apache.commons.collections.LRUMap;
+import org.apache.velocity.runtime.RuntimeConstants;
import org.apache.velocity.runtime.RuntimeServices;
/**
* Default implementation of the resource cache for the default
- * ResourceManager.
+ * ResourceManager. The cache uses a <i>least recently used</i> (LRU)
+ * algorithm, with a maximum size specified via the
+ * <code>resource.manager.cache.size</code> property (idenfied by the
+ * {@link
+ * org.apache.velocity.runtime.RuntimeConstants#RESOURCE_MANAGER_CACHE_SIZE}
+ * constant). This property get be set to <code>0</code> or less for
+ * a greedy, unbounded cache (the behavior from pre-v1.5).
*
* @author <a href="mailto:geirm@apache.org">Geir Magnusson Jr.</a>
* @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
@@ -83,8 +93,18 @@
public void initialize( RuntimeServices rs )
{
rsvc = rs;
-
- rsvc.info("ResourceCache : initialized. (" + this.getClass() + ")");
+
+ int maxSize =
+ rsvc.getInt(RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE, 89);
+ if (maxSize > 0)
+ {
+ // Create a whole new Map here to avoid hanging on to a
+ // handle to the unsynch'd LRUMap for our lifetime.
+ Map lruCache = Collections.synchronizedMap(new LRUMap(maxSize));
+ lruCache.putAll(cache);
+ cache = lruCache;
+ }
+ rsvc.info("ResourceCache : initialized. (" + this.getClass() + ')');
}
public Resource get( Object key )
1.34 +18 -5 jakarta-velocity/src/java/org/apache/velocity/runtime/RuntimeConstants.java
Index: RuntimeConstants.java
===================================================================
RCS file: /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/RuntimeConstants.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -u -r1.33 -r1.34
--- RuntimeConstants.java 29 Apr 2003 00:22:07 -0000 1.33
+++ RuntimeConstants.java 22 Oct 2003 03:00:46 -0000 1.34
@@ -254,11 +254,24 @@
* ----------------------------------------------------------------------
*/
- public static String RESOURCE_MANAGER_CLASS = "resource.manager.class";
-
- public static String RESOURCE_MANAGER_CACHE_CLASS =
+ public static String RESOURCE_MANAGER_CLASS = "resource.manager.class";
+
+ /**
+ * The <code>resource.manager.cache.class</code> property
+ * specifies the name of the {@link
+ * org.apache.velocity.runtime.resource.ResourceCache}
+ * implementation to use.
+ */
+ public static String RESOURCE_MANAGER_CACHE_CLASS =
"resource.manager.cache.class";
-
+
+ /**
+ * The <code>resource.manager.cache.size</code> property specifies
+ * the cache upper bound (if relevant).
+ */
+ public static String RESOURCE_MANAGER_CACHE_SIZE =
+ "resource.manager.cache.size";
+
/*
* ----------------------------------------------------------------------
* R E S O U R C E L O A D E R C O N F I G U R A T I O N
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>
>>On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
>>
>>>Geir Magnusson Jr. wrote:
>>>...
>>>
>>>>You might have some legs to stand on for the second one, as that
>>>>allows you to override the cache class, which I think is the general
>>>>operation, but the third is clearly targeted for the default
>>>>implementation.
>>>
>>>Yes, the third does apply to the default implementation. Bounding of
>>>caches should is encouraged behavior. Having a cache which grows
>>>without bound is a memory leak waiting to happen, easy to trigger in
>>>environments with a high fixed or variable number of resources.
>>
>>I can't see what anything but the first sentence is relevant.
>
> i believe the point is that other implementations of ResourceCache are both
> able and encouraged to use that same property. they are not, however,
> required to make use of it. if the property name/key is changed to indicate
> that it is only to be used for the default implementation (as you suggest),
> then other ResourceCache implementations that wish to have a bound on the
> cache size will likely end up implementing their own property name/key. why
> not just leave the property as is and let any implementation make use of it
> that so chooses?
>
> if i understand Dan correctly on this, then i agree with what he's saying.
Nathan, that was what I was trying to say. Thanks for clearing things up.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Thursday, October 23, 2003, at 06:40 PM, Nathan Bubna wrote:
...
>> i believe the point is that other implementations of ResourceCache are
>> both
>> able and encouraged to use that same property. they are not, however,
>> required to make use of it. if the property name/key is changed to
>> indicate
>> that it is only to be used for the default implementation (as you
>> suggest),
>> then other ResourceCache implementations that wish to have a bound on the
>> cache size will likely end up implementing their own property
>> name/key. why
>> not just leave the property as is and let any implementation make use
>> of it
>> that so chooses?
>
> Because whether it has an effect is then arbitrary.
Yes, that is the intent -- whether or not to limit size should be left up to
the use case of the ResourceCache implementor.
> If it's something specific to the default implementation, then we should
> make that clear in the name. That way, if they switch the
> configuration, they aren't surprised when the 'size' property has zero
> effect. And the developer of the new cache impl shouldn't be required
> to support a velocity-implementation defined property.
The "size" property happens to be acknowledged by the only ResourceCache
implementation shipped with Velocity, yes. However, if someone configures a
different cache implementation, they're in a a very different class of users,
and are much more likely to read documentation because they're either a)
implementing their own cache or b) using someone else's implementation which
is likely to provide some degree of documentation since it's reusable.
> If we want to force the notion of settable size to be respected, or at
> least make the implementing programmer aware of the concept, we should
> put it in the interface, rather than have it off in some piece of
> documentation that lists the velocity properties.
I wouldn't be against putting it in the interface. It's more work from an
implementor's perspective when they don't want a maximum size (something I was
originally trying to avoid), but maybe that's what we want after all? Setting
a maximum cache size should certainly be encouraged.
Removing the constant from the public API entirely or moving it to
ResourceCacheImpl is another reasonable option, if you continue to feel that
it's specific to ResourceCacheImpl. If the cache size was removed from
RuntimeConstants, I'd care a lot less about its name and semantics.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Thursday, October 30, 2003, at 12:32 AM, Daniel L. Rall wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
>>>
>>>> Geir Magnusson Jr. wrote:
>>>>
>>>>> FYI : I'm not trying to be argumentative. I just was reminded of
>>>>> lingering things when slapping myself today about the fact that our
>>>>> [] returns an ArrayList and not a List. It's a subtle issue, but
>>>>> boy I wish we made it a List...
>>>>
>>>> What do you say about that happening in 2.x?
>>>>
>>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
>>>
>>> Well, it was just an aesthetic objection. I'm 100% sure we'd break
>>> people if we did that. I guess the question is if it's worth it.
>>
>> Yeah, we might break some people. But looking at the type of breakage
>> (compile-time 99.9% of the time) and the degree of difficulty of
>> fixing (trivial search and replace), doing it as part of a major
>> version number bump is reasonable.
>
> I don't believe it would be compile time at all, because the compiler
> has no clue what is going to happen in a case like :
>
> #set($foo = [0..10])
>
> $thingy.myMethod($foo)
Indeed, that doesn't occur until runtime, after parsing of the AST. But I
wasn't suggesting we alter the underlying returned ArrayList implementation of
List. Like you say below, people will only be hosed if we change that.
> If we returned a List w/ ArrayList as impl, I think we're still ok
> though. For cases where you exploit the knowledge of an ArrayList, you
> might do something like :
>
> $thingy.myMethod($foo.toArray())
>
> In which case you are hosed if we change the impl underneath. I don't
> know if changing to List now, and jumping up and down in the docs about
> assuming the impl would solve it.
Agreed, but even then backwards compatibility can be preserved transparently.
If there's ever a desire to move to a List implementation other than ArrayList,
use of a marker interface for special-casing the methods of ArrayList which
extend what's provided by the List API could be provided. Making the List
implementation pluggable would be slightly more difficult, but still possible.
Do you like the color of my sky today?
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 30, 2003, at 12:32 AM, Daniel L. Rall wrote:
> Geir Magnusson Jr. wrote:
>> On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
>>> Geir Magnusson Jr. wrote:
>>>
>>>> FYI : I'm not trying to be argumentative. I just was reminded of
>>>> lingering things when slapping myself today about the fact that our
>>>> [] returns an ArrayList and not a List. It's a subtle issue, but
>>>> boy I wish we made it a List...
>>>
>>>
>>> What do you say about that happening in 2.x?
>>>
>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
>> Well, it was just an aesthetic objection. I'm 100% sure we'd break
>> people if we did that. I guess the question is if it's worth it.
>
> Yeah, we might break some people. But looking at the type of breakage
> (compile-time 99.9% of the time) and the degree of difficulty of
> fixing (trivial search and replace), doing it as part of a major
> version number bump is reasonable.
I don't believe it would be compile time at all, because the compiler
has no clue what is going to happen in a case like :
#set($foo = [0..10])
$thingy.myMethod($foo)
If we returned a List w/ ArrayList as impl, I think we're still ok
though. For cases where you exploit the knowledge of an ArrayList, you
might do something like :
$thingy.myMethod($foo.toArray())
In which case you are hosed if we change the impl underneath. I don't
know if changing to List now, and jumping up and down in the docs about
assuming the impl would solve it.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> FYI : I'm not trying to be argumentative. I just was reminded of
>>> lingering things when slapping myself today about the fact that our
>>> [] returns an ArrayList and not a List. It's a subtle issue, but boy
>>> I wish we made it a List...
>>
>>
>> What do you say about that happening in 2.x?
>>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
>
>
> Well, it was just an aesthetic objection. I'm 100% sure we'd break
> people if we did that. I guess the question is if it's worth it.
Yeah, we might break some people. But looking at the type of breakage
(compile-time 99.9% of the time) and the degree of difficulty of fixing
(trivial search and replace), doing it as part of a major version number bump
is reasonable.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, October 28, 2003, at 10:45 PM, Daniel L. Rall wrote:
> Geir Magnusson Jr. wrote:
>> FYI : I'm not trying to be argumentative. I just was reminded of
>> lingering things when slapping myself today about the fact that our
>> [] returns an ArrayList and not a List. It's a subtle issue, but boy
>> I wish we made it a List...
>
> What do you say about that happening in 2.x?
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
Well, it was just an aesthetic objection. I'm 100% sure we'd break
people if we did that. I guess the question is if it's worth it.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
> FYI : I'm not trying to be argumentative. I just was reminded of
> lingering things when slapping myself today about the fact that our []
> returns an ArrayList and not a List. It's a subtle issue, but boy I
> wish we made it a List...
What do you say about that happening in 2.x?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24203
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
FYI : I'm not trying to be argumentative. I just was reminded of
lingering things when slapping myself today about the fact that our []
returns an ArrayList and not a List. It's a subtle issue, but boy I
wish we made it a List...
geir
On Thursday, October 23, 2003, at 06:56 PM, Geir Magnusson Jr. wrote:
>
> On Thursday, October 23, 2003, at 06:40 PM, Nathan Bubna wrote:
>
>> Geir Magnusson Jr. said:
>>> On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
>>>> Geir Magnusson Jr. wrote:
>>>> ...
>>>>> You might have some legs to stand on for the second one, as that
>>>>> allows you to override the cache class, which I think is the
>>>>> general
>>>>> operation, but the third is clearly targeted for the default
>>>>> implementation.
>>>>
>>>> Yes, the third does apply to the default implementation. Bounding
>>>> of
>>>> caches should is encouraged behavior. Having a cache which grows
>>>> without bound is a memory leak waiting to happen, easy to trigger in
>>>> environments with a high fixed or variable number of resources.
>>>
>>> I can't see what anything but the first sentence is relevant.
>>
>> i believe the point is that other implementations of ResourceCache
>> are both
>> able and encouraged to use that same property. they are not, however,
>> required to make use of it. if the property name/key is changed to
>> indicate
>> that it is only to be used for the default implementation (as you
>> suggest),
>> then other ResourceCache implementations that wish to have a bound on
>> the
>> cache size will likely end up implementing their own property
>> name/key. why
>> not just leave the property as is and let any implementation make use
>> of it
>> that so chooses?
>
> Because whether it has an effect is then arbitrary.
>
> If it's something specific to the default implementation, then we
> should make that clear in the name. That way, if they switch the
> configuration, they aren't surprised when the 'size' property has zero
> effect. And the developer of the new cache impl shouldn't be required
> to support a velocity-implementation defined property.
>
> If we want to force the notion of settable size to be respected, or at
> least make the implementing programmer aware of the concept, we should
> put it in the interface, rather than have it off in some piece of
> documentation that lists the velocity properties.
>
> geir
>
>>
>> Nathan Bubna
>> nathan@esha.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
> --
> Geir Magnusson Jr 203-247-1713(m)
> geirm@optonline.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 23, 2003, at 06:40 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
>>> Geir Magnusson Jr. wrote:
>>> ...
>>>> You might have some legs to stand on for the second one, as that
>>>> allows you to override the cache class, which I think is the
>>>> general
>>>> operation, but the third is clearly targeted for the default
>>>> implementation.
>>>
>>> Yes, the third does apply to the default implementation. Bounding of
>>> caches should is encouraged behavior. Having a cache which grows
>>> without bound is a memory leak waiting to happen, easy to trigger in
>>> environments with a high fixed or variable number of resources.
>>
>> I can't see what anything but the first sentence is relevant.
>
> i believe the point is that other implementations of ResourceCache are
> both
> able and encouraged to use that same property. they are not, however,
> required to make use of it. if the property name/key is changed to
> indicate
> that it is only to be used for the default implementation (as you
> suggest),
> then other ResourceCache implementations that wish to have a bound on
> the
> cache size will likely end up implementing their own property
> name/key. why
> not just leave the property as is and let any implementation make use
> of it
> that so chooses?
Because whether it has an effect is then arbitrary.
If it's something specific to the default implementation, then we
should make that clear in the name. That way, if they switch the
configuration, they aren't surprised when the 'size' property has zero
effect. And the developer of the new cache impl shouldn't be required
to support a velocity-implementation defined property.
If we want to force the notion of settable size to be respected, or at
least make the implementing programmer aware of the concept, we should
put it in the interface, rather than have it off in some piece of
documentation that lists the velocity properties.
geir
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
> > Geir Magnusson Jr. wrote:
> > ...
> >> You might have some legs to stand on for the second one, as that
> >> allows you to override the cache class, which I think is the general
> >> operation, but the third is clearly targeted for the default
> >> implementation.
> >
> > Yes, the third does apply to the default implementation. Bounding of
> > caches should is encouraged behavior. Having a cache which grows
> > without bound is a memory leak waiting to happen, easy to trigger in
> > environments with a high fixed or variable number of resources.
>
> I can't see what anything but the first sentence is relevant.
i believe the point is that other implementations of ResourceCache are both
able and encouraged to use that same property. they are not, however,
required to make use of it. if the property name/key is changed to indicate
that it is only to be used for the default implementation (as you suggest),
then other ResourceCache implementations that wish to have a bound on the
cache size will likely end up implementing their own property name/key. why
not just leave the property as is and let any implementation make use of it
that so chooses?
if i understand Dan correctly on this, then i agree with what he's saying.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 23, 2003, at 05:09 PM, Daniel Rall wrote:
> Geir Magnusson Jr. wrote:
> ...
>> You might have some legs to stand on for the second one, as that
>> allows you to override the cache class, which I think is the general
>> operation, but the third is clearly targeted for the default
>> implementation.
>
> Yes, the third does apply to the default implementation. Bounding of
> caches should is encouraged behavior. Having a cache which grows
> without bound is a memory leak waiting to happen, easy to trigger in
> environments with a high fixed or variable number of resources.
I can't see what anything but the first sentence is relevant.
>
> Abstractly, consider cache sizing as part of the interface, which
> implementations can implement as a no-op if they choose (by not using
> or ignoring the parameter). I would've added a new API method
> directly to the ResourceCache Java interface, but that would require
> additional work for users upgrading their custom implementations.
>
I'm not arguing about the size. I think it's great. What I do think
is that we should fix these property names while we have a chance...
> - Dan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
...
> You might
> have some legs to stand on for the second one, as that allows you to
> override the cache class, which I think is the general operation, but
> the third is clearly targeted for the default implementation.
Yes, the third does apply to the default implementation. Bounding of caches
should is encouraged behavior. Having a cache which grows without bound is a
memory leak waiting to happen, easy to trigger in environments with a high fixed
or variable number of resources.
Abstractly, consider cache sizing as part of the interface, which
implementations can implement as a no-op if they choose (by not using or
ignoring the parameter). I would've added a new API method directly to the
ResourceCache Java interface, but that would require additional work for users
upgrading their custom implementations.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Resource cache configuration parameters
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 23, 2003, at 11:57 AM, Daniel L. Rall wrote:
> Geir Magnusson Jr. wrote:
>> On Wednesday, October 22, 2003, at 02:34 PM, Daniel Rall wrote:
>>> Geir Magnusson Jr. wrote:
>>>
>>>> On Wednesday, October 22, 2003, at 01:14 PM, Daniel L. Rall wrote:
>>>>
>>>>> Yes, you'd have to set the cache size to less than 1 to get the
>>>>> old greedy behavior. This is a feature, not a bug, as the old
>>>>> behavior retained memory based on the number of resources
>>>>> (templates, etc.) that were loaded and subsequently cached.
>>>>>
>>>>> I documented that in the changes.xml file. Should we provide a
>>>>> more thorough example?
>>>>
>>>> Well, we might want to doc, but the behavior seems to be benign.
>>>
>>>
>>> To where should I add the additional documentation?
>> Thought about this. I threw the two params into the dev guide as I
>> was in there for log4j update.
>> I also tweaked the name of the param to
>> resource.manager.defaultcache.size to keep people from thinking it
>> affected anything but the default cache. If you don't like, bellow >> :)
>
> Okay, wooooof!! I dislike the inconsistency with the other default
> cache properties, which are all named using the
> "resource.manager.cache" prefix even though they refer to the default
> cache. Here's the relevant constants from RuntimeConstants:
>
> -----------------------------------------------------------------------
> --------
> public static String RESOURCE_MANAGER_CLASS =
> "resource.manager.class";
>
> /**
> * The <code>resource.manager.cache.class</code> property
> * specifies the name of the {@link
> * org.apache.velocity.runtime.resource.ResourceCache}
> * implementation to use.
> */
> public static String RESOURCE_MANAGER_CACHE_CLASS =
> "resource.manager.cache.class";
>
> /**
> * The <code>resource.manager.cache.size</code> property specifies
> * the cache upper bound (if relevant).
> */
> public static String RESOURCE_MANAGER_DEFAULTCACHE_SIZE =
> "resource.manager.defaultcache.size";
> -----------------------------------------------------------------------
> --------
>
> This last one now sticks out like a sore thumb. Since all these
> parameters speak of the default implementation, they must be named
> consistently.
No they don't.
The first allows you to replace the resource manager class. You might
have some legs to stand on for the second one, as that allows you to
override the cache class, which I think is the general operation, but
the third is clearly targeted for the default implementation.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Resource cache configuration parameters
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Wednesday, October 22, 2003, at 02:34 PM, Daniel Rall wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> On Wednesday, October 22, 2003, at 01:14 PM, Daniel L. Rall wrote:
>>>
>>>> Yes, you'd have to set the cache size to less than 1 to get the old
>>>> greedy behavior. This is a feature, not a bug, as the old behavior
>>>> retained memory based on the number of resources (templates, etc.)
>>>> that were loaded and subsequently cached.
>>>>
>>>> I documented that in the changes.xml file. Should we provide a
>>>> more thorough example?
>>>
>>> Well, we might want to doc, but the behavior seems to be benign.
>>
>>
>> To where should I add the additional documentation?
>
>
> Thought about this. I threw the two params into the dev guide as I was
> in there for log4j update.
>
> I also tweaked the name of the param to
> resource.manager.defaultcache.size to keep people from thinking it
> affected anything but the default cache. If you don't like, bellow :)
Okay, wooooof!! I dislike the inconsistency with the other default cache
properties, which are all named using the "resource.manager.cache" prefix even
though they refer to the default cache. Here's the relevant constants from
RuntimeConstants:
-------------------------------------------------------------------------------
public static String RESOURCE_MANAGER_CLASS = "resource.manager.class";
/**
* The <code>resource.manager.cache.class</code> property
* specifies the name of the {@link
* org.apache.velocity.runtime.resource.ResourceCache}
* implementation to use.
*/
public static String RESOURCE_MANAGER_CACHE_CLASS =
"resource.manager.cache.class";
/**
* The <code>resource.manager.cache.size</code> property specifies
* the cache upper bound (if relevant).
*/
public static String RESOURCE_MANAGER_DEFAULTCACHE_SIZE =
"resource.manager.defaultcache.size";
-------------------------------------------------------------------------------
This last one now sticks out like a sore thumb. Since all these parameters
speak of the default implementation, they must be named consistently.
To the best of my knowledge we don't allow named caches, so even though the
"size" parameter is not part of Velocity's ResourceCache interface like the
"class" parameter is, they both still refer to configuration for the same
instance. For an alternate ResourceCache implementation, the size parameter
may not be relevant, but in such a case the developer of that alternate
implementation is likely to read the JavaDoc for the corresponding constant,
note the "if relevant" comment, and leave the parameter out from his class's
configuration. For the casual user who doesn't implement their own cache
(easily 90%+ of our user base), they needn't be confused by the parameter
naming inconsistency.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/runtime RuntimeConstants.java
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, October 22, 2003, at 02:34 PM, Daniel Rall wrote:
> Geir Magnusson Jr. wrote:
>> On Wednesday, October 22, 2003, at 01:14 PM, Daniel L. Rall wrote:
>>> Yes, you'd have to set the cache size to less than 1 to get the old
>>> greedy behavior. This is a feature, not a bug, as the old behavior
>>> retained memory based on the number of resources (templates, etc.)
>>> that were loaded and subsequently cached.
>>>
>>> I documented that in the changes.xml file. Should we provide a
>>> more thorough example?
>> Well, we might want to doc, but the behavior seems to be benign.
>
> To where should I add the additional documentation?
Thought about this. I threw the two params into the dev guide as I was
in there for log4j update.
I also tweaked the name of the param to
resource.manager.defaultcache.size to keep people from thinking it
affected anything but the default cache. If you don't like, bellow :)
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/runtime
RuntimeConstants.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Geir Magnusson Jr. wrote:
>
> On Wednesday, October 22, 2003, at 01:14 PM, Daniel L. Rall wrote:
>
>> Yes, you'd have to set the cache size to less than 1 to get the old
>> greedy behavior. This is a feature, not a bug, as the old behavior
>> retained memory based on the number of resources (templates, etc.)
>> that were loaded and subsequently cached.
>>
>> I documented that in the changes.xml file. Should we provide a more
>> thorough example?
>
>
> Well, we might want to doc, but the behavior seems to be benign.
To where should I add the additional documentation?
> No idea from what hat you pulled the default value of '89', though...
89 is a good size for a hash structure. I think there are several numbers in
the 30's range which are also good. I'd have to look it up in an algorithms
book again (as was done for 89 last year).
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/runtime RuntimeConstants.java
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, October 22, 2003, at 01:14 PM, Daniel L. Rall wrote:
> Yes, you'd have to set the cache size to less than 1 to get the old
> greedy behavior. This is a feature, not a bug, as the old behavior
> retained memory based on the number of resources (templates, etc.)
> that were loaded and subsequently cached.
>
> I documented that in the changes.xml file. Should we provide a more
> thorough example?
Well, we might want to doc, but the behavior seems to be benign. No
idea from what hat you pulled the default value of '89', though...
>
> Geir Magnusson Jr. wrote:
>> Doesn't this mean you have to set the cache size to get the previous
>> behavior?
>> On Tuesday, October 21, 2003, at 11:00 PM, dlr@apache.org wrote:
>>> dlr 2003/10/21 20:00:47
>>>
>>> Modified: docs developer-guide.html changes.html
>>> xdocs developer-guide.xml changes.xml
>>> src/java/org/apache/velocity/runtime/resource
>>> ResourceCacheImpl.java
>>> src/java/org/apache/velocity/runtime
>>> RuntimeConstants.java
>>> Log:
>>> *
>>> src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java
>>> initialize(RuntimeServices): Leveraged LRUMap from Commons
>>> Collections. If the resource.manager.cache.size property is set
>>> to
>>> 0 or less, the previous greedy behavior is available.
>>>
>>> * src/java/org/apache/velocity/runtime/RuntimeConstants.java
>>> RESOURCE_MANAGER_CACHE_CLASS: Added JavaDoc.
>>>
>>> RESOURCE_MANAGER_CACHE_SIZE: New constant for the resource cache
>>> size property.
>>>
>>> * xdocs/developer-guide.xml
>>> * docs/developer-guide.html
>>> Mentioned the RESOURCE_MANAGER_CACHE_SIZE
>>> (resource.manager.cache.size) property.
>>>
>>> * xdocs/changes.xml
>>> * docs/changes.html
>>> Noted new LRUMap implementation of ResourceCacheImpl.
>>>
>>> * TODO.txt
>>> Removed the "Control Caching Resource Usage" item.
>>>
>>> Revision Changes Path
>>> 1.103 +31 -0 jakarta-velocity/docs/developer-guide.html
>>>
>>> Index: developer-guide.html
>>> ===================================================================
>>> RCS file: /home/cvs/jakarta-velocity/docs/developer-guide.html,v
>>> retrieving revision 1.102
>>> retrieving revision 1.103
>>> diff -u -u -r1.102 -r1.103
>>> --- developer-guide.html 21 Oct 2003 12:05:36 -0000 1.102
>>> +++ developer-guide.html 22 Oct 2003 03:00:46 -0000 1.103
>>> @@ -3195,6 +3195,37 @@
>>> This key is also defined as a contstant
>>> <code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
>>> </p>
>>> + <p>
>>> +A resource cache implementation may want to limit the cache size
>>> +(rather than providing an unbounded cache which could consume all
>>> +available memory). To configure Velocity to set the size for your
>>> +cache, use the configuration key:
>>> +</p>
>>> + <div
>>> align="left">
>>> + <table cellspacing="4" cellpadding="0" border="0">
>>> + <tr>
>>> + <td bgcolor="#023264" width="1" height="1"><img
>>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>>> border="0"/></td>
>>> + <td bgcolor="#023264" height="1"><img
>>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>>> border="0"/></td>
>>> + <td bgcolor="#023264" width="1" height="1"><img
>>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>>> border="0"/></td>
>>> + </tr>
>>> + <tr>
>>> + <td bgcolor="#023264" width="1"><img src="/images/void.gif"
>>> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
>>> + <td bgcolor="#ffffff"><pre>
>>> +resource.manager.cache.size
>>> +</pre></td>
>>> + <td bgcolor="#023264" width="1"><img src="/images/void.gif"
>>> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
>>> + </tr>
>>> + <tr>
>>> + <td bgcolor="#023264" width="1" height="1"><img
>>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>>> border="0"/></td>
>>> + <td bgcolor="#023264" height="1"><img
>>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>>> border="0"/></td>
>>> + <td bgcolor="#023264" width="1" height="1"><img
>>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>>> border="0"/></td>
>>> + </tr>
>>> + </table>
>>> + </div>
>>> + <p>
>>> +This key is also defined as a contstant
>>> +<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
>>> +</p>
>>> </blockquote>
>>> </p>
>>> </td></tr>
>>>
>>>
>>>
>>> 1.104 +10 -1 jakarta-velocity/docs/changes.html
>>>
>>> Index: changes.html
>>> ===================================================================
>>> RCS file: /home/cvs/jakarta-velocity/docs/changes.html,v
>>> retrieving revision 1.103
>>> retrieving revision 1.104
>>> diff -u -u -r1.103 -r1.104
>>> --- changes.html 22 Oct 2003 02:04:01 -0000 1.103
>>> +++ changes.html 22 Oct 2003 03:00:46 -0000 1.104
>>> @@ -169,8 +169,17 @@
>>> references, and Category.getInstance() with Logger.getLogger().
>>> (#19133) (dlr)
>>> </li>
>>> <li>
>>> -Decommissioned the long-deprecated Log4JLogSystem. Never fear,
>>> +Removed the long-deprecated Log4JLogSystem. Never fear,
>>> SimpleLog4JLogSystem remains. (dlr)
>>> +</li>
>>> +<li>
>>> +Enhanced the implementation of ResourceCacheImpl using Jakarta
>>> Commons
>>> +Collections LRUMap class. The previous greedy implementation did
>>> not
>>> +set an upper bound for the cache size, meaning that cached
>>> resources
>>> +were never relinquished (a possible memory leak). You can
>>> continue to
>>> +use that behavior by setting the
>>> +<code>resource.manager.cache.size</code> for your cache to less
>>> than
>>> +1. (dlr)
>>> </li>
>>> </ul>
>>> </blockquote>
>>>
>>>
>>>
>>> 1.70 +16 -0 jakarta-velocity/xdocs/developer-guide.xml
>>>
>>> Index: developer-guide.xml
>>> ===================================================================
>>> RCS file: /home/cvs/jakarta-velocity/xdocs/developer-guide.xml,v
>>> retrieving revision 1.69
>>> retrieving revision 1.70
>>> diff -u -u -r1.69 -r1.70
>>> --- developer-guide.xml 27 Jan 2003 21:06:27 -0000 1.69
>>> +++ developer-guide.xml 22 Oct 2003 03:00:46 -0000 1.70
>>> @@ -2590,6 +2590,22 @@
>>> <code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
>>> </p>
>>>
>>> +<p>
>>> +A resource cache implementation may want to limit the cache size
>>> +(rather than providing an unbounded cache which could consume all
>>> +available memory). To configure Velocity to set the size for your
>>> +cache, use the configuration key:
>>> +</p>
>>> +
>>> +<source><![CDATA[
>>> +resource.manager.cache.size
>>> +]]></source>
>>> +
>>> +<p>
>>> +This key is also defined as a contstant
>>> +<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
>>> +</p>
>>> +
>>> </section>
>>>
>>>
>>>
>>> <section name="Template Encoding for Internationalization">
>>>
>>>
>>>
>>>
>>> 1.96 +9 -0 jakarta-velocity/xdocs/changes.xml
>>>
>>> Index: changes.xml
>>> ===================================================================
>>> RCS file: /home/cvs/jakarta-velocity/xdocs/changes.xml,v
>>> retrieving revision 1.95
>>> retrieving revision 1.96
>>> diff -u -u -r1.95 -r1.96
>>> --- changes.xml 22 Oct 2003 02:04:01 -0000 1.95
>>> +++ changes.xml 22 Oct 2003 03:00:46 -0000 1.96
>>> @@ -32,6 +32,15 @@
>>> Removed the long-deprecated Log4JLogSystem. Never fear,
>>> SimpleLog4JLogSystem remains. (dlr)
>>> </li>
>>> +<li>
>>> +Enhanced the implementation of ResourceCacheImpl using Jakarta
>>> Commons
>>> +Collections LRUMap class. The previous greedy implementation did
>>> not
>>> +set an upper bound for the cache size, meaning that cached
>>> resources
>>> +were never relinquished (a possible memory leak). You can
>>> continue to
>>> +use that behavior by setting the
>>> +<code>resource.manager.cache.size</code> for your cache to less
>>> than
>>> +1. (dlr)
>>> +</li>
>>> </ul>
>>>
>>> </subsection>
>>>
>>>
>>>
>>> 1.3 +24 -4
>>> jakarta-velocity/src/java/org/apache/velocity/runtime/resource/
>>> ResourceCacheImpl.java
>>>
>>> Index: ResourceCacheImpl.java
>>> ===================================================================
>>> RCS file:
>>> /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/
>>> resource/ResourceCacheImpl.java,v
>>> retrieving revision 1.2
>>> retrieving revision 1.3
>>> diff -u -u -r1.2 -r1.3
>>> --- ResourceCacheImpl.java 12 Feb 2002 19:08:06 -0000 1.2
>>> +++ ResourceCacheImpl.java 22 Oct 2003 03:00:46 -0000 1.3
>>> @@ -54,14 +54,24 @@
>>> * <http://www.apache.org/>.
>>> */
>>>
>>> +import java.util.Collections;
>>> import java.util.Hashtable;
>>> import java.util.Map;
>>> import java.util.Iterator;
>>> +
>>> +import org.apache.commons.collections.LRUMap;
>>> +import org.apache.velocity.runtime.RuntimeConstants;
>>> import org.apache.velocity.runtime.RuntimeServices;
>>>
>>> /**
>>> * Default implementation of the resource cache for the default
>>> - * ResourceManager.
>>> + * ResourceManager. The cache uses a <i>least recently used</i>
>>> (LRU)
>>> + * algorithm, with a maximum size specified via the
>>> + * <code>resource.manager.cache.size</code> property (idenfied by
>>> the
>>> + * {@link
>>> + *
>>> org.apache.velocity.runtime.RuntimeConstants#RESOURCE_MANAGER_CACHE_S
>>> IZ E}
>>> + * constant). This property get be set to <code>0</code> or less
>>> for
>>> + * a greedy, unbounded cache (the behavior from pre-v1.5).
>>> *
>>> * @author <a href="mailto:geirm@apache.org">Geir Magnusson
>>> Jr.</a>
>>> * @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
>>> @@ -83,8 +93,18 @@
>>> public void initialize( RuntimeServices rs )
>>> {
>>> rsvc = rs;
>>> -
>>> - rsvc.info("ResourceCache : initialized. (" +
>>> this.getClass() + ")");
>>> +
>>> + int maxSize =
>>> +
>>> rsvc.getInt(RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE, 89);
>>> + if (maxSize > 0)
>>> + {
>>> + // Create a whole new Map here to avoid hanging on to
>>> a
>>> + // handle to the unsynch'd LRUMap for our lifetime.
>>> + Map lruCache = Collections.synchronizedMap(new
>>> LRUMap(maxSize));
>>> + lruCache.putAll(cache);
>>> + cache = lruCache;
>>> + }
>>> + rsvc.info("ResourceCache : initialized. (" +
>>> this.getClass() + ')');
>>> }
>>>
>>> public Resource get( Object key )
>>>
>>>
>>>
>>> 1.34 +18 -5
>>> jakarta-velocity/src/java/org/apache/velocity/runtime/
>>> RuntimeConstants.java
>>>
>>> Index: RuntimeConstants.java
>>> ===================================================================
>>> RCS file:
>>> /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/
>>> RuntimeConstants.java,v
>>> retrieving revision 1.33
>>> retrieving revision 1.34
>>> diff -u -u -r1.33 -r1.34
>>> --- RuntimeConstants.java 29 Apr 2003 00:22:07 -0000 1.33
>>> +++ RuntimeConstants.java 22 Oct 2003 03:00:46 -0000 1.34
>>> @@ -254,11 +254,24 @@
>>> *
>>> ---------------------------------------------------------------------
>>> -
>>> */
>>>
>>> - public static String RESOURCE_MANAGER_CLASS =
>>> "resource.manager.class";
>>> -
>>> - public static String RESOURCE_MANAGER_CACHE_CLASS =
>>> + public static String RESOURCE_MANAGER_CLASS =
>>> "resource.manager.class";
>>> +
>>> + /**
>>> + * The <code>resource.manager.cache.class</code> property
>>> + * specifies the name of the {@link
>>> + * org.apache.velocity.runtime.resource.ResourceCache}
>>> + * implementation to use.
>>> + */
>>> + public static String RESOURCE_MANAGER_CACHE_CLASS =
>>> "resource.manager.cache.class";
>>> -
>>> +
>>> + /**
>>> + * The <code>resource.manager.cache.size</code> property
>>> specifies
>>> + * the cache upper bound (if relevant).
>>> + */
>>> + public static String RESOURCE_MANAGER_CACHE_SIZE =
>>> + "resource.manager.cache.size";
>>> +
>>> /*
>>> *
>>> ---------------------------------------------------------------------
>>> -
>>> * R E S O U R C E L O A D E R C O N F I G U R A T I O N
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/runtime
RuntimeConstants.java
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Yes, you'd have to set the cache size to less than 1 to get the old greedy
behavior. This is a feature, not a bug, as the old behavior retained memory
based on the number of resources (templates, etc.) that were loaded and
subsequently cached.
I documented that in the changes.xml file. Should we provide a more thorough
example?
Geir Magnusson Jr. wrote:
> Doesn't this mean you have to set the cache size to get the previous
> behavior?
>
> On Tuesday, October 21, 2003, at 11:00 PM, dlr@apache.org wrote:
>
>> dlr 2003/10/21 20:00:47
>>
>> Modified: docs developer-guide.html changes.html
>> xdocs developer-guide.xml changes.xml
>> src/java/org/apache/velocity/runtime/resource
>> ResourceCacheImpl.java
>> src/java/org/apache/velocity/runtime
>> RuntimeConstants.java
>> Log:
>> * src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java
>> initialize(RuntimeServices): Leveraged LRUMap from Commons
>> Collections. If the resource.manager.cache.size property is set to
>> 0 or less, the previous greedy behavior is available.
>>
>> * src/java/org/apache/velocity/runtime/RuntimeConstants.java
>> RESOURCE_MANAGER_CACHE_CLASS: Added JavaDoc.
>>
>> RESOURCE_MANAGER_CACHE_SIZE: New constant for the resource cache
>> size property.
>>
>> * xdocs/developer-guide.xml
>> * docs/developer-guide.html
>> Mentioned the RESOURCE_MANAGER_CACHE_SIZE
>> (resource.manager.cache.size) property.
>>
>> * xdocs/changes.xml
>> * docs/changes.html
>> Noted new LRUMap implementation of ResourceCacheImpl.
>>
>> * TODO.txt
>> Removed the "Control Caching Resource Usage" item.
>>
>> Revision Changes Path
>> 1.103 +31 -0 jakarta-velocity/docs/developer-guide.html
>>
>> Index: developer-guide.html
>> ===================================================================
>> RCS file: /home/cvs/jakarta-velocity/docs/developer-guide.html,v
>> retrieving revision 1.102
>> retrieving revision 1.103
>> diff -u -u -r1.102 -r1.103
>> --- developer-guide.html 21 Oct 2003 12:05:36 -0000 1.102
>> +++ developer-guide.html 22 Oct 2003 03:00:46 -0000 1.103
>> @@ -3195,6 +3195,37 @@
>> This key is also defined as a contstant
>> <code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
>> </p>
>> + <p>
>> +A resource cache implementation may want to limit the cache size
>> +(rather than providing an unbounded cache which could consume all
>> +available memory). To configure Velocity to set the size for your
>> +cache, use the configuration key:
>> +</p>
>> + <div
>> align="left">
>> + <table cellspacing="4" cellpadding="0" border="0">
>> + <tr>
>> + <td bgcolor="#023264" width="1" height="1"><img
>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>> border="0"/></td>
>> + <td bgcolor="#023264" height="1"><img src="/images/void.gif"
>> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
>> + <td bgcolor="#023264" width="1" height="1"><img
>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>> border="0"/></td>
>> + </tr>
>> + <tr>
>> + <td bgcolor="#023264" width="1"><img src="/images/void.gif"
>> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
>> + <td bgcolor="#ffffff"><pre>
>> +resource.manager.cache.size
>> +</pre></td>
>> + <td bgcolor="#023264" width="1"><img src="/images/void.gif"
>> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
>> + </tr>
>> + <tr>
>> + <td bgcolor="#023264" width="1" height="1"><img
>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>> border="0"/></td>
>> + <td bgcolor="#023264" height="1"><img src="/images/void.gif"
>> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
>> + <td bgcolor="#023264" width="1" height="1"><img
>> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
>> border="0"/></td>
>> + </tr>
>> + </table>
>> + </div>
>> + <p>
>> +This key is also defined as a contstant
>> +<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
>> +</p>
>> </blockquote>
>> </p>
>> </td></tr>
>>
>>
>>
>> 1.104 +10 -1 jakarta-velocity/docs/changes.html
>>
>> Index: changes.html
>> ===================================================================
>> RCS file: /home/cvs/jakarta-velocity/docs/changes.html,v
>> retrieving revision 1.103
>> retrieving revision 1.104
>> diff -u -u -r1.103 -r1.104
>> --- changes.html 22 Oct 2003 02:04:01 -0000 1.103
>> +++ changes.html 22 Oct 2003 03:00:46 -0000 1.104
>> @@ -169,8 +169,17 @@
>> references, and Category.getInstance() with Logger.getLogger().
>> (#19133) (dlr)
>> </li>
>> <li>
>> -Decommissioned the long-deprecated Log4JLogSystem. Never fear,
>> +Removed the long-deprecated Log4JLogSystem. Never fear,
>> SimpleLog4JLogSystem remains. (dlr)
>> +</li>
>> +<li>
>> +Enhanced the implementation of ResourceCacheImpl using Jakarta
>> Commons
>> +Collections LRUMap class. The previous greedy implementation did not
>> +set an upper bound for the cache size, meaning that cached resources
>> +were never relinquished (a possible memory leak). You can
>> continue to
>> +use that behavior by setting the
>> +<code>resource.manager.cache.size</code> for your cache to less than
>> +1. (dlr)
>> </li>
>> </ul>
>> </blockquote>
>>
>>
>>
>> 1.70 +16 -0 jakarta-velocity/xdocs/developer-guide.xml
>>
>> Index: developer-guide.xml
>> ===================================================================
>> RCS file: /home/cvs/jakarta-velocity/xdocs/developer-guide.xml,v
>> retrieving revision 1.69
>> retrieving revision 1.70
>> diff -u -u -r1.69 -r1.70
>> --- developer-guide.xml 27 Jan 2003 21:06:27 -0000 1.69
>> +++ developer-guide.xml 22 Oct 2003 03:00:46 -0000 1.70
>> @@ -2590,6 +2590,22 @@
>> <code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
>> </p>
>>
>> +<p>
>> +A resource cache implementation may want to limit the cache size
>> +(rather than providing an unbounded cache which could consume all
>> +available memory). To configure Velocity to set the size for your
>> +cache, use the configuration key:
>> +</p>
>> +
>> +<source><![CDATA[
>> +resource.manager.cache.size
>> +]]></source>
>> +
>> +<p>
>> +This key is also defined as a contstant
>> +<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
>> +</p>
>> +
>> </section>
>>
>>
>>
>> <section name="Template Encoding for Internationalization">
>>
>>
>>
>>
>> 1.96 +9 -0 jakarta-velocity/xdocs/changes.xml
>>
>> Index: changes.xml
>> ===================================================================
>> RCS file: /home/cvs/jakarta-velocity/xdocs/changes.xml,v
>> retrieving revision 1.95
>> retrieving revision 1.96
>> diff -u -u -r1.95 -r1.96
>> --- changes.xml 22 Oct 2003 02:04:01 -0000 1.95
>> +++ changes.xml 22 Oct 2003 03:00:46 -0000 1.96
>> @@ -32,6 +32,15 @@
>> Removed the long-deprecated Log4JLogSystem. Never fear,
>> SimpleLog4JLogSystem remains. (dlr)
>> </li>
>> +<li>
>> +Enhanced the implementation of ResourceCacheImpl using Jakarta
>> Commons
>> +Collections LRUMap class. The previous greedy implementation did not
>> +set an upper bound for the cache size, meaning that cached resources
>> +were never relinquished (a possible memory leak). You can
>> continue to
>> +use that behavior by setting the
>> +<code>resource.manager.cache.size</code> for your cache to less than
>> +1. (dlr)
>> +</li>
>> </ul>
>>
>> </subsection>
>>
>>
>>
>> 1.3 +24 -4
>> jakarta-velocity/src/java/org/apache/velocity/runtime/resource/
>> ResourceCacheImpl.java
>>
>> Index: ResourceCacheImpl.java
>> ===================================================================
>> RCS file:
>> /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/
>> resource/ResourceCacheImpl.java,v
>> retrieving revision 1.2
>> retrieving revision 1.3
>> diff -u -u -r1.2 -r1.3
>> --- ResourceCacheImpl.java 12 Feb 2002 19:08:06 -0000 1.2
>> +++ ResourceCacheImpl.java 22 Oct 2003 03:00:46 -0000 1.3
>> @@ -54,14 +54,24 @@
>> * <http://www.apache.org/>.
>> */
>>
>> +import java.util.Collections;
>> import java.util.Hashtable;
>> import java.util.Map;
>> import java.util.Iterator;
>> +
>> +import org.apache.commons.collections.LRUMap;
>> +import org.apache.velocity.runtime.RuntimeConstants;
>> import org.apache.velocity.runtime.RuntimeServices;
>>
>> /**
>> * Default implementation of the resource cache for the default
>> - * ResourceManager.
>> + * ResourceManager. The cache uses a <i>least recently used</i>
>> (LRU)
>> + * algorithm, with a maximum size specified via the
>> + * <code>resource.manager.cache.size</code> property (idenfied by the
>> + * {@link
>> + *
>> org.apache.velocity.runtime.RuntimeConstants#RESOURCE_MANAGER_CACHE_SIZ
>> E}
>> + * constant). This property get be set to <code>0</code> or less for
>> + * a greedy, unbounded cache (the behavior from pre-v1.5).
>> *
>> * @author <a href="mailto:geirm@apache.org">Geir Magnusson Jr.</a>
>> * @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
>> @@ -83,8 +93,18 @@
>> public void initialize( RuntimeServices rs )
>> {
>> rsvc = rs;
>> -
>> - rsvc.info("ResourceCache : initialized. (" +
>> this.getClass() + ")");
>> +
>> + int maxSize =
>> +
>> rsvc.getInt(RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE, 89);
>> + if (maxSize > 0)
>> + {
>> + // Create a whole new Map here to avoid hanging on to a
>> + // handle to the unsynch'd LRUMap for our lifetime.
>> + Map lruCache = Collections.synchronizedMap(new
>> LRUMap(maxSize));
>> + lruCache.putAll(cache);
>> + cache = lruCache;
>> + }
>> + rsvc.info("ResourceCache : initialized. (" +
>> this.getClass() + ')');
>> }
>>
>> public Resource get( Object key )
>>
>>
>>
>> 1.34 +18 -5
>> jakarta-velocity/src/java/org/apache/velocity/runtime/
>> RuntimeConstants.java
>>
>> Index: RuntimeConstants.java
>> ===================================================================
>> RCS file:
>> /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/
>> RuntimeConstants.java,v
>> retrieving revision 1.33
>> retrieving revision 1.34
>> diff -u -u -r1.33 -r1.34
>> --- RuntimeConstants.java 29 Apr 2003 00:22:07 -0000 1.33
>> +++ RuntimeConstants.java 22 Oct 2003 03:00:46 -0000 1.34
>> @@ -254,11 +254,24 @@
>> *
>> ----------------------------------------------------------------------
>> */
>>
>> - public static String RESOURCE_MANAGER_CLASS =
>> "resource.manager.class";
>> -
>> - public static String RESOURCE_MANAGER_CACHE_CLASS =
>> + public static String RESOURCE_MANAGER_CLASS =
>> "resource.manager.class";
>> +
>> + /**
>> + * The <code>resource.manager.cache.class</code> property
>> + * specifies the name of the {@link
>> + * org.apache.velocity.runtime.resource.ResourceCache}
>> + * implementation to use.
>> + */
>> + public static String RESOURCE_MANAGER_CACHE_CLASS =
>> "resource.manager.cache.class";
>> -
>> +
>> + /**
>> + * The <code>resource.manager.cache.size</code> property
>> specifies
>> + * the cache upper bound (if relevant).
>> + */
>> + public static String RESOURCE_MANAGER_CACHE_SIZE =
>> + "resource.manager.cache.size";
>> +
>> /*
>> *
>> ----------------------------------------------------------------------
>> * R E S O U R C E L O A D E R C O N F I G U R A T I O N
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/runtime RuntimeConstants.java
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Doesn't this mean you have to set the cache size to get the previous
behavior?
On Tuesday, October 21, 2003, at 11:00 PM, dlr@apache.org wrote:
> dlr 2003/10/21 20:00:47
>
> Modified: docs developer-guide.html changes.html
> xdocs developer-guide.xml changes.xml
> src/java/org/apache/velocity/runtime/resource
> ResourceCacheImpl.java
> src/java/org/apache/velocity/runtime
> RuntimeConstants.java
> Log:
> *
> src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java
> initialize(RuntimeServices): Leveraged LRUMap from Commons
> Collections. If the resource.manager.cache.size property is set to
> 0 or less, the previous greedy behavior is available.
>
> * src/java/org/apache/velocity/runtime/RuntimeConstants.java
> RESOURCE_MANAGER_CACHE_CLASS: Added JavaDoc.
>
> RESOURCE_MANAGER_CACHE_SIZE: New constant for the resource cache
> size property.
>
> * xdocs/developer-guide.xml
> * docs/developer-guide.html
> Mentioned the RESOURCE_MANAGER_CACHE_SIZE
> (resource.manager.cache.size) property.
>
> * xdocs/changes.xml
> * docs/changes.html
> Noted new LRUMap implementation of ResourceCacheImpl.
>
> * TODO.txt
> Removed the "Control Caching Resource Usage" item.
>
> Revision Changes Path
> 1.103 +31 -0 jakarta-velocity/docs/developer-guide.html
>
> Index: developer-guide.html
> ===================================================================
> RCS file: /home/cvs/jakarta-velocity/docs/developer-guide.html,v
> retrieving revision 1.102
> retrieving revision 1.103
> diff -u -u -r1.102 -r1.103
> --- developer-guide.html 21 Oct 2003 12:05:36 -0000 1.102
> +++ developer-guide.html 22 Oct 2003 03:00:46 -0000 1.103
> @@ -3195,6 +3195,37 @@
> This key is also defined as a contstant
> <code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
> </p>
> + <p>
> +A resource cache implementation may want to limit the cache size
> +(rather than providing an unbounded cache which could consume all
> +available memory). To configure Velocity to set the size for your
> +cache, use the configuration key:
> +</p>
> + <div
> align="left">
> + <table cellspacing="4" cellpadding="0" border="0">
> + <tr>
> + <td bgcolor="#023264" width="1" height="1"><img
> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
> border="0"/></td>
> + <td bgcolor="#023264" height="1"><img src="/images/void.gif"
> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
> + <td bgcolor="#023264" width="1" height="1"><img
> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
> border="0"/></td>
> + </tr>
> + <tr>
> + <td bgcolor="#023264" width="1"><img src="/images/void.gif"
> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
> + <td bgcolor="#ffffff"><pre>
> +resource.manager.cache.size
> +</pre></td>
> + <td bgcolor="#023264" width="1"><img src="/images/void.gif"
> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
> + </tr>
> + <tr>
> + <td bgcolor="#023264" width="1" height="1"><img
> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
> border="0"/></td>
> + <td bgcolor="#023264" height="1"><img src="/images/void.gif"
> width="1" height="1" vspace="0" hspace="0" border="0"/></td>
> + <td bgcolor="#023264" width="1" height="1"><img
> src="/images/void.gif" width="1" height="1" vspace="0" hspace="0"
> border="0"/></td>
> + </tr>
> + </table>
> + </div>
> + <p>
> +This key is also defined as a contstant
> +<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
> +</p>
> </blockquote>
> </p>
> </td></tr>
>
>
>
> 1.104 +10 -1 jakarta-velocity/docs/changes.html
>
> Index: changes.html
> ===================================================================
> RCS file: /home/cvs/jakarta-velocity/docs/changes.html,v
> retrieving revision 1.103
> retrieving revision 1.104
> diff -u -u -r1.103 -r1.104
> --- changes.html 22 Oct 2003 02:04:01 -0000 1.103
> +++ changes.html 22 Oct 2003 03:00:46 -0000 1.104
> @@ -169,8 +169,17 @@
> references, and Category.getInstance() with Logger.getLogger().
> (#19133) (dlr)
> </li>
> <li>
> -Decommissioned the long-deprecated Log4JLogSystem. Never fear,
> +Removed the long-deprecated Log4JLogSystem. Never fear,
> SimpleLog4JLogSystem remains. (dlr)
> +</li>
> +<li>
> +Enhanced the implementation of ResourceCacheImpl using Jakarta
> Commons
> +Collections LRUMap class. The previous greedy implementation did
> not
> +set an upper bound for the cache size, meaning that cached resources
> +were never relinquished (a possible memory leak). You can continue
> to
> +use that behavior by setting the
> +<code>resource.manager.cache.size</code> for your cache to less than
> +1. (dlr)
> </li>
> </ul>
> </blockquote>
>
>
>
> 1.70 +16 -0 jakarta-velocity/xdocs/developer-guide.xml
>
> Index: developer-guide.xml
> ===================================================================
> RCS file: /home/cvs/jakarta-velocity/xdocs/developer-guide.xml,v
> retrieving revision 1.69
> retrieving revision 1.70
> diff -u -u -r1.69 -r1.70
> --- developer-guide.xml 27 Jan 2003 21:06:27 -0000 1.69
> +++ developer-guide.xml 22 Oct 2003 03:00:46 -0000 1.70
> @@ -2590,6 +2590,22 @@
> <code>RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS</code>
> </p>
>
> +<p>
> +A resource cache implementation may want to limit the cache size
> +(rather than providing an unbounded cache which could consume all
> +available memory). To configure Velocity to set the size for your
> +cache, use the configuration key:
> +</p>
> +
> +<source><![CDATA[
> +resource.manager.cache.size
> +]]></source>
> +
> +<p>
> +This key is also defined as a contstant
> +<code>RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE</code>
> +</p>
> +
> </section>
>
>
>
> <section name="Template Encoding for Internationalization">
>
>
>
>
> 1.96 +9 -0 jakarta-velocity/xdocs/changes.xml
>
> Index: changes.xml
> ===================================================================
> RCS file: /home/cvs/jakarta-velocity/xdocs/changes.xml,v
> retrieving revision 1.95
> retrieving revision 1.96
> diff -u -u -r1.95 -r1.96
> --- changes.xml 22 Oct 2003 02:04:01 -0000 1.95
> +++ changes.xml 22 Oct 2003 03:00:46 -0000 1.96
> @@ -32,6 +32,15 @@
> Removed the long-deprecated Log4JLogSystem. Never fear,
> SimpleLog4JLogSystem remains. (dlr)
> </li>
> +<li>
> +Enhanced the implementation of ResourceCacheImpl using Jakarta
> Commons
> +Collections LRUMap class. The previous greedy implementation did
> not
> +set an upper bound for the cache size, meaning that cached resources
> +were never relinquished (a possible memory leak). You can continue
> to
> +use that behavior by setting the
> +<code>resource.manager.cache.size</code> for your cache to less than
> +1. (dlr)
> +</li>
> </ul>
>
> </subsection>
>
>
>
> 1.3 +24 -4
> jakarta-velocity/src/java/org/apache/velocity/runtime/resource/
> ResourceCacheImpl.java
>
> Index: ResourceCacheImpl.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/
> resource/ResourceCacheImpl.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -u -r1.2 -r1.3
> --- ResourceCacheImpl.java 12 Feb 2002 19:08:06 -0000 1.2
> +++ ResourceCacheImpl.java 22 Oct 2003 03:00:46 -0000 1.3
> @@ -54,14 +54,24 @@
> * <http://www.apache.org/>.
> */
>
> +import java.util.Collections;
> import java.util.Hashtable;
> import java.util.Map;
> import java.util.Iterator;
> +
> +import org.apache.commons.collections.LRUMap;
> +import org.apache.velocity.runtime.RuntimeConstants;
> import org.apache.velocity.runtime.RuntimeServices;
>
> /**
> * Default implementation of the resource cache for the default
> - * ResourceManager.
> + * ResourceManager. The cache uses a <i>least recently used</i>
> (LRU)
> + * algorithm, with a maximum size specified via the
> + * <code>resource.manager.cache.size</code> property (idenfied by
> the
> + * {@link
> + *
> org.apache.velocity.runtime.RuntimeConstants#RESOURCE_MANAGER_CACHE_SIZ
> E}
> + * constant). This property get be set to <code>0</code> or less
> for
> + * a greedy, unbounded cache (the behavior from pre-v1.5).
> *
> * @author <a href="mailto:geirm@apache.org">Geir Magnusson Jr.</a>
> * @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
> @@ -83,8 +93,18 @@
> public void initialize( RuntimeServices rs )
> {
> rsvc = rs;
> -
> - rsvc.info("ResourceCache : initialized. (" +
> this.getClass() + ")");
> +
> + int maxSize =
> +
> rsvc.getInt(RuntimeConstants.RESOURCE_MANAGER_CACHE_SIZE, 89);
> + if (maxSize > 0)
> + {
> + // Create a whole new Map here to avoid hanging on to a
> + // handle to the unsynch'd LRUMap for our lifetime.
> + Map lruCache = Collections.synchronizedMap(new
> LRUMap(maxSize));
> + lruCache.putAll(cache);
> + cache = lruCache;
> + }
> + rsvc.info("ResourceCache : initialized. (" +
> this.getClass() + ')');
> }
>
> public Resource get( Object key )
>
>
>
> 1.34 +18 -5
> jakarta-velocity/src/java/org/apache/velocity/runtime/
> RuntimeConstants.java
>
> Index: RuntimeConstants.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-velocity/src/java/org/apache/velocity/runtime/
> RuntimeConstants.java,v
> retrieving revision 1.33
> retrieving revision 1.34
> diff -u -u -r1.33 -r1.34
> --- RuntimeConstants.java 29 Apr 2003 00:22:07 -0000 1.33
> +++ RuntimeConstants.java 22 Oct 2003 03:00:46 -0000 1.34
> @@ -254,11 +254,24 @@
> *
> ----------------------------------------------------------------------
> */
>
> - public static String RESOURCE_MANAGER_CLASS =
> "resource.manager.class";
> -
> - public static String RESOURCE_MANAGER_CACHE_CLASS =
> + public static String RESOURCE_MANAGER_CLASS =
> "resource.manager.class";
> +
> + /**
> + * The <code>resource.manager.cache.class</code> property
> + * specifies the name of the {@link
> + * org.apache.velocity.runtime.resource.ResourceCache}
> + * implementation to use.
> + */
> + public static String RESOURCE_MANAGER_CACHE_CLASS =
> "resource.manager.cache.class";
> -
> +
> + /**
> + * The <code>resource.manager.cache.size</code> property
> specifies
> + * the cache upper bound (if relevant).
> + */
> + public static String RESOURCE_MANAGER_CACHE_SIZE =
> + "resource.manager.cache.size";
> +
> /*
> *
> ----------------------------------------------------------------------
> * R E S O U R C E L O A D E R C O N F I G U R A T I O N
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org