Final verdict on removing reference to RuntimeSingleton

["Anthony E. Carlos" <an...@digitalphenom.com>]

Hello all,

I followed the thread, "Need to remove reference to the 
RuntimeSingleton" because my web app is not releasing memory when I 
reload.  Here is my setup:

jakarta-tomcat-5.0.28
jakarta-struts-1.1
jakarta-log4j-1.2.8
db-ojb-1.0.0
and of course, velocity-1.4.

I used JProfiler and found that 
org.apache.velocity.runtime.RuntimeSingleton is the garbage collector 
root of a whole bunch of objects that are not collected when I reload a 
context in Tomcat (using the manager web app).

My question, then, is this: was it finally decided that Tomcat is 
responsible for the memory leak? (I'm using version 5 and the thread 
below was on Tomcat 4-- you'd think that it would be solved by now). 
What's the final verdict on this? Better yet, what can I do to prevent 
the memory leak? Am I supposed to add some code to my Struts Actions to 
uninitialize Velocity? (That doesn't make sense since 
VelocityViewServlet is what's creating my response page-- how can I 
uninitialize it before it's done it's job?).

Does anyone know of any articles that teach someone how to write a web 
app that releases all its memory when it's reloaded?

Thanks,

-Anthony Carlos



On 2/18/02 3:35 PM, "Jim Rudnicki" <[EMAIL PROTECTED]> wrote:

 > How about adding a method
 >
 > Velocity.uninit()
 >
 > All well behaved users of init() would call this when the engine was 
no
 > longer used.  Count calls to init() and only destroy the engine 
instance
 > when the count goes back to zero -- reference counted singleton.  
Servlets
 > call init() in their init() and uninit() in their destroy().
 >
 > This should allow the servlet container to unload the servlet and the
 > Velocity engine will be safely destroyed when it can.
 >
 > Yeh this is somewhat trying to do what the GC should do for us, but 
it also
 > gives explicit control of the life cycle of the engine for those who
 > need/desire.
 >

Thomas searched deeper into the tomcat code, and appears to have found 
the
problem - he posted to tomcat-dev with his suggestion, and Remy seems to
agree with him.

Thanks so much to Thomas for the excellent detective work....

So we'll assume that indeed this is tomcat, and won't worry about it in
velocity?

-- 
Geir Magnusson Jr.                                     [EMAIL PROTECTED]
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++... 


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

Re: Final verdict on removing reference to RuntimeSingleton

[Nathan Bubna <na...@esha.com>]

Anthony E. Carlos said:
> I followed the thread, "Need to remove reference to the
> RuntimeSingleton" because my web app is not releasing memory when I
> reload.
...
> I used JProfiler and found that
> org.apache.velocity.runtime.RuntimeSingleton is the garbage collector
> root of a whole bunch of objects that are not collected when I reload a
> context in Tomcat (using the manager web app).
>
> My question, then, is this: was it finally decided that Tomcat is
> responsible for the memory leak? (I'm using version 5 and the thread
> below was on Tomcat 4-- you'd think that it would be solved by now).
> What's the final verdict on this? Better yet, what can I do to prevent
> the memory leak?

i'm not sure there's a whole lot you can do.  i've also noticed Tomcat reloads
accumulating memory with each reload, and when i went searching the mailing
lists, i recall learning that that is because the discarded classloaders can't
be garbage collected.  in a large and complex app like mine, that means a lot
of Class objects getting stuck in memory.  and apparently, it means the
singleton and all its references aren't getting recycled either.

unfortunately, if that's the case, then the only thing i can think of is to
get away from using the singleton, and i haven't had the time to finish
making/testing the changes to VelocityTools necessary to do that.  they've
been sitting idle on my local machine for some time now, as i have had to
prioritize paid work, school, and abundant personal issues in recent months.
:(

> Am I supposed to add some code to my Struts Actions to
> uninitialize Velocity? (That doesn't make sense since
> VelocityViewServlet is what's creating my response page-- how can I
> uninitialize it before it's done it's job?).
>
> Does anyone know of any articles that teach someone how to write a web
> app that releases all its memory when it's reloaded?
>
> Thanks,
>
> -Anthony Carlos
>
>
>
> On 2/18/02 3:35 PM, "Jim Rudnicki" <[EMAIL PROTECTED]> wrote:
>
>  > How about adding a method
>  >
>  > Velocity.uninit()
>  >
>  > All well behaved users of init() would call this when the engine was
> no
>  > longer used.  Count calls to init() and only destroy the engine
> instance
>  > when the count goes back to zero -- reference counted singleton.
> Servlets
>  > call init() in their init() and uninit() in their destroy().
>  >
>  > This should allow the servlet container to unload the servlet and the
>  > Velocity engine will be safely destroyed when it can.
>  >
>  > Yeh this is somewhat trying to do what the GC should do for us, but
> it also
>  > gives explicit control of the life cycle of the engine for those who
>  > need/desire.
>  >
>
> Thomas searched deeper into the tomcat code, and appears to have found
> the
> problem - he posted to tomcat-dev with his suggestion, and Remy seems to
> agree with him.
>
> Thanks so much to Thomas for the excellent detective work....
>
> So we'll assume that indeed this is tomcat, and won't worry about it in
> velocity?
>
> -- 
> Geir Magnusson Jr.                                     [EMAIL PROTECTED]
> System and Software Consulting
> Java : the speed of Smalltalk with the simple elegance of C++...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org