Hi Paul Must be this you mean?
--- Jelly uses ThreadLocal variables inside TagScript objects in order to enable thread safety. Unfortunately, in an environment that performs thread pooling, this means that much of the memory used by Jelly is never eligable for garbage collection. If you pool enough threads, this can lead to out-of-memory errors. One workaround is for the end-user to always launch Jelly scripts in their own threads. However, this is not ideal. Jelly should be modified so that it handles memory efficiently when used inside of a thread pool. --- Seems like this is still somehow an issue. And to my understanding, the Jetspeed portal is using thread pooling (pls correct me if wrong) so that might be a reason. But a solution, hmmm, still far away I guess. Anyone else, ideas? Thx /Kristofer -----Original Message----- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Thursday, September 16, 2004 10:42 PM To: Jakarta Commons Users List Subject: Re: [Jelly] compiling scripts causes memory leaks Kristofer, There was a leak-issue filed in Jira, I think it was kind of closed... it had to do with re-used threads. paul Le 16 sept. 04, � 18:22, Kristofer Eriksson a �crit : > Hi all, > > > > am a big fan of Jelly and am happy to see the progress with the latest > beta > 4 release. Congratulations all of you involved. > > > > I am using it now (heavily) in a portal dev project (Jetspeed) and > having > problems with performance and "memory leaks". My tests have shown that > when > using real time compilation of scripts the memory used by tomcat is > growing > rapidly under load. I have compared real time compilation and pre > compiled > scripts and there is definitively a big difference. > > > > Is this something known, have someone experienced the same, and most > important: can it be prevented? I suppose it could have to do with the > xml > parser used, and not jelly itself, but my knowledge there is not on an > expert level. > > > > Within the app, I am using dynamic scripts so I cannot pre-compile > everything, so that suggestion will not give me much help:-) > > > > Pls, any help/info appreciated. > > > > Kind Regards > > > > /Kristofer Eriksson > > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
