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/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
