I think I jumped to the conclusion that Daryl was using JSTL 1.1 and
hence made the JSP 2.0 -> J2EE 1.4 -> J2SE 1.4 connections. Since we're
really talking about JSTL 1.0 (JSP1.2 -> J2EE 1.3), I think we're
required to support J2SE 1.3. I'm not sure I like taking on the
dependency, but the Collections project already contains the classes
org.apache.commons.collections.LRUMap (v.2.1.1) and
org.apache.commons.collections.map.LRUMap (v.3.1). I can't seem to put a
finger on the J2SE requirements for Collections though...
Justyna Horwat wrote:
Hi Daryl,
There is actually a bug report already filed:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30136
One possible solution that Kris mentioned is using an LRU cache. We
could do something as follows in ELEvaluator.java:
----
final int MAX_ENTRIES = 100; //*** profiling would help here ***
static Map sCachedExpressionStrings =
Collections.synchronizedMap(
Map cache = new LinkedHashMap (MAX_ENTRIES + 1, .75F, true) {
public boolean removeEldestEntry(Map.Entry eldest) {
return size() > MAX_ENTRIES;
}
}
);
----
I don't have any profilers setup so I'd appreciate your analysis of
these changes.
I also need to investigate the impact of adding a J2SE 1.4 dependency in
the codebase. If it's a problem then we may need to do our own
LinkedHashMap implementation.
Thanks,
Justyna
Kris Schneider wrote:
Definitely file a bug in bugzilla. Before a fix gets coded, however,
there has
to be some developer (meaning committer) consensus on what the fix
actually is.
This is the correct forum for the discussion and hopefully the bug
report will
spur additional comments.
Quoting Daryl Beattie <[EMAIL PROTECTED]>:
Okay.... So I'm not used to this; how does the task of fixing this
problem get assigned? Should I open a bug in bugzilla for it?
I'd gladly work on it and see what I can get done (as long as I can ask
you developers for assistance if I need to know how something works).
The only question mark in my mind right now is where to put the
configuration option, but I'm sure once I start digging through the code
I'd find it easily enough.
- Daryl.
-----Original Message-----
From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Tuesday, October
19, 2004 2:43 PM
To: Tag Libraries Developers List
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
Some quick options off the top of my head:
J2EE 1.4 requires J2SE 1.4, so we could create an LRU cache with
LinkedHashMap (override the removeEldestEntry method).
We could also implement a cache using reference objects.
Since ELEvaluator already has a constructor arg for bypassing the cache,
we could expose a way to configure its use. I think the only place one
is currently created is as a singleton within Evaluator. Obviously, this
could also be combined with a more memory-friendly cache.
Quoting Daryl Beattie <[EMAIL PROTECTED]>:
Hi everyone,
Following up on the memory leak; I have found that the
"possible"
memory leak in the ELEvaluator is indeed a real memory leak. Beyond
profiling to find the bug, I have gone to the trouble of disabling the
sCachedExpressionStrings cache in ELEvaluator, recompiling the
standard taglib, deploying and re-testing with the cache-disabled jar.
What I found is that indeed the leak did disappear, and after
running under a load for 8 hours my app was using the same amount of
memory as
it had used in the first 20 minutes.
So it definitely is a leak.
What should be done about it? Is there a last-recently-used map
that
we could be using instead of just a regular HashMap? Should I stick
with my cache-disabled jar?
I would like to know how you folks would like to handle the bug
so
that I can eventually get a new version of the standard taglib.
Otherwise, I'll be stuck deploying my hacked jar and relying on my own
hacked version of the taglib. Let me know if there's any way I can
help to get this problem fixed; I'd be glad to volunteer some effort
and even some profiling testing.
Sincerely,
Daryl.
-----Original Message-----
From: Daryl Beattie [mailto:[EMAIL PROTECTED]
Sent: Friday, October 15, 2004 5:40 PM
To: [EMAIL PROTECTED]
Subject: Possible Memory Leak in ELEvaluator.java (standard v1.0.6)
Hi everybody,
I have a question about a possible memory leak in
ELEvaluator.java. I have noticed when profiling that HashMap entries
(containing Strings, etc.) are kept by the sCachedExpressionStrings
static variable and never removed. Over the course of running an
application for several hours that uses tags that have evaluations
in them, this Map builds up in memory -- in fact I noticed that it
was 343k for just one tag alone after I ran my app for 5 minutes. I
have dynamically constructed expressions, and am concerned that each
one is
being cached even if that expression is never used again.
Would it be prudent to use some other kind of Collection to
store these cached expressions (such as one that times out its entries
after a certain amount of time)?
Also, I have toyed with the idea of adding functionality to
permanently disable the cache, but since I do not know the expense
of creating a new ELParser with the String expression, I do not know
if this will cripple my system. I believe I have a normal percentage
of re-used expressions across my tags.
I also find it interesting that there is functionality to
bypass getting values from the cache, but there is not yet a way to
disable its use. Even when bypassing the cache, the cache grows over
time.
What do you think about this possible leak?
Sincerely,
Daryl.
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
