HttpSeesion.removeAttribute does not garbage collect object 2005-06-30 - By Partha Ranjan Das
Back
Hi Jerry,
This is a stateless session bean.
Regards,
Partha
-- --Original Message-- --
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition [mailto:J2EE
-INTEREST@(protected)]On Behalf Of Jerry Osme?a
Sent: Wednesday, June 29, 2005 11:49 PM
To: J2EE-INTEREST@(protected)
Subject: Re: HttpSeesion.removeAttribute does not garbage collect object
Removing the object from the session only means that object is available for
garbage collection. It does not guarantee though that it will be garbage
collected immediately when garbage collection process takes place. It depends
on how your JVM(I think it depends per application server, for example, BEA has
its proprietary implementation of JVM called JRockit) implemented or used the
particular garbage collection algorithm. Hence, this explains why the recently
removed object from session is not garbage collected yet.
Per with half of objects are still in Web and EJB tier, what kind of EJB did
you call, it is a stateless or staful session bean? or it is a entity bean that
is passed back to web?
Partha Ranjan Das <partharanjan.d@(protected)> wrote:
Hi J2EE Gurus,
We are having a seemingly peculiar problem.
In this case an activeX client makes multiple HTTP calls to a servelt in a web
server serially. The servlet has a single method to handle all these HTTP calls
(called "FP calls") . This method has many switch-case statements for these FP
calls. In the first "case" statement, it calls the EJB tier and gets a
collection of serializeable Value Object (Or Data Transfer Objects) and this
collection is maintained in the HttpSession by using HttpSession.setAttribute(
"XYZ",object). Now, when the following call, made by the same ActiveX client,
(in this FP series of calls) comes for the next FP call, it uses the collection
stored in session. The last FP call, after doing business operations, does
HttpSession.removeAttribute("XYZ"). So at this point, we assume that this
collection, which was so far bound to key "XYZ", should be ready for garbage
collection....right?
Wrong. When we ran JProfiler to find what all objects are there in the memory
at this point (after calling GC manually using the profiler),--- we find that
those objects, constituting that collection, which is supposed to be garbage
collected, are not at all garbage collected. What is more ashtonishing is that
we find half of these objects are lying in the EJB tier and half in the web
tier. But the servlet responds to all the FP calls and the ActiveX displays all
the information required. This means that the HTTP responses for all the HTTP
"FP call" requests have been duely and fully made.
Does anybody have any idea why, after calling session.removeAttribute also,
these objects are not garbage collected and also why half of these objects are
still lying in the EJB tier, even after EJB method has ended and GC is called
using the profiler? We are not maintaining this collection as a static
propoerty of any of the classes, either in web or EJB tier. We are using WSAD 5
.1.
Thanks in advance,
Regards,
Partha
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
__ __
Yahoo! Sports
Rekindle <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=33539/*http:/
/football.fantasysports.yahoo.com?ovchn=YAH&ovcpn=Integration&ovcrn=Mail+footer
&ovrfd=YAH&ovtac=AD> the Rivalries. Sign up for Fantasy Football ===============
============================================================ To unsubscribe,
send email to listserv@(protected) and include in the body of the message
"signoff J2EE-INTEREST". For general help, send email to listserv@(protected)
and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859 (See http://iso-8859.ora-code.com)-1">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=265515904-30062005><FONT face=Arial color=#0000ff size=2>Hi
Jerry,</FONT></SPAN></DIV>
<DIV><SPAN class=265515904-30062005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=265515904-30062005><FONT face=Arial color=#0000ff size=2>This
is a stateless session bean.</FONT></SPAN></DIV>
<DIV><SPAN class=265515904-30062005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=265515904-30062005><FONT face=Arial color=#0000ff
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=265515904-30062005><FONT face=Arial color=#0000ff
size=2>Partha</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-- --Original Message-- --<BR><B>From:</B> A mailing list for Java(tm)
2 Platform, Enterprise Edition [mailto:J2EE-INTEREST@(protected)]<B>On
Behalf
Of </B>Jerry Osme?a<BR><B>Sent:</B> Wednesday, June 29, 2005 11:49
PM<BR><B>To:</B> J2EE-INTEREST@(protected)<BR><B>Subject:</B> Re:
HttpSeesion.removeAttribute does not garbage collect
object<BR><BR></FONT></DIV>
<DIV>Removing the object from the session only means that object is available
for garbage collection. It does not guarantee though that it will be garbage
collected immediately when garbage collection process takes place. It depends
on how your JVM(I think it depends per application server,
for example, BEA has its proprietary implementation of JVM called
JRockit) implemented or used the particular garbage collection algorithm.
Hence, this explains why the recently removed object from session is not
garbage collected yet.</DIV>
<DIV> </DIV>
<DIV>Per with half of objects are still in Web and EJB tier, what kind of EJB
did you call, it is a stateless or staful session bean? or it is a entity
bean
that is passed back to web?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><B><I>Partha Ranjan Das
<partharanjan.d@(protected)></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"
>Hi
J2EE Gurus,<BR><BR>We are having a seemingly peculiar problem.<BR><BR>In
this case an activeX client makes multiple HTTP calls to a servelt in a web
server serially. The servlet has a single method to handle all these HTTP
calls (called "FP calls") . This method has many switch-case statements for
these FP calls. In the first "case" statement, it calls the EJB tier and
gets a collection of serializeable Value Object (Or Data Transfer Objects)
and this collection is maintained in the HttpSession by using
HttpSession.setAttribute("XYZ",object). Now, when the following call, made
by the same ActiveX client, (in this FP series of calls) comes for the next
FP call, it uses the collection stored in session. The last FP call, after
doing business operations, does HttpSession.removeAttribute("XYZ"). So at
this point, we assume that this collection, which was so far bound to key
"XYZ", should be ready for garbage collection....right?<BR>Wrong. When we
ran JProfiler to find what all objects are there in the memory at this
point
(after calling GC manually using the profiler),--- we find that those
objects, constituting that collection, which is supposed to be garbage
collected, are not at all garbage collected. What is more ashtonishing is
that we find half of these objects are lying in the EJB tier and half in
the
web tier. But the servlet responds to all the FP calls and the ActiveX
displays all the information required. This means that the HTTP responses
for all the HTTP "FP call" requests have been duely and fully made.<BR>Does
anybody have any idea why, after calling session.removeAttribute also,
these
objects are not garbage collected and also why half of these objects are
still lying in the EJB tier, even after EJB method has ended and GC is
called using the profiler? We are not maintaining this collection as a
static propoerty of any of the classes, either in web or EJB tier. We are
using WSAD 5.1.<BR>Thanks in
advance,<BR><BR>Regards,<BR>Partha<BR><BR>=================================
==========================================<BR>To
unsubscribe, send email to listserv@(protected) and include in the
body<BR>of the message "signoff J2EE-INTEREST". For general help, send
email
to<BR>listserv@(protected) and include in the body of the message
"help".<BR></BLOCKQUOTE>
<P>
<HR SIZE=1>
Yahoo! Sports<BR><A
href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=33539/*http://football
.fantasysports.yahoo.com?ovchn=YAH&ovcpn=Integration&ovcrn=Mail+footer
&ovrfd=YAH&ovtac=AD ">Rekindle
the Rivalries. Sign up for Fantasy Football</A>
===========================================================================
To
unsubscribe, send email to listserv@(protected) and include in the body of
the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
<P></P></BLOCKQUOTE></BODY></HTML>
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
<p>
|
|
