portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: Memory leakage in Jetspeed
Date Fri, 02 Sep 2005 05:16:57 GMT
Sujit Menon wrote:

>Hey randy,
>Thanks for your response.
>Since the memory drop was during test I thought I will try for a single user login.
>I started jetpseed2 server & logged in as admin to the application. What I noticed
in jconsole was there was a usage of 20mb. After the user session timed out after 1 minute
the memory still was not going down to normal usage.
>Can you please tell me why this is happening even for one user?
>
I would expect that it is impossible to verify any memory issues with a 
single session. Here is what I'd do in your position:

1. generate a repeatable test;
2. set the container session timeout to <=2 minutes in web.xml;
3. set it running for a LONG time, (the longer the better), at a 
CONSTANT rate;
4. use a memory monitoring tool, (such as the Memory tab of jconsole), 
and plot the slope of the memory troughs that occur immedately after a 
GC execution.

If over time you find that no plateau is reached, that would seem to 
indicate a possible memory leak. There are other techniques I would use 
to further pin down any possible leak including runtime GC report trends 
and heap dumps after a long run. Yes, identifying memory leaks is 
non-trivial unless you get lucky somewhere along the way!

HTH,

Randy

>
>
>Regards
>Sujit
>-----Original Message-----
>From: Randy Watler [mailto:watler@wispertel.net]
>Sent: Friday, September 02, 2005 3:14 AM
>To: Jetspeed Developers List
>Subject: Re: Memory leakage in Jetspeed
>
>Sujit:
>
>Memory is indeed consumed with each active session in J2. To control the
>number of sessions created while stress/load testing J2, you need to use
>an actual browser as a client or use a scriptable client that has
>enabled "cookie jar" support. The JSESSIONID cookie send by the servlet
>container must be set in the client and included in every subsequent
>request that is intended to be part of a simulated session. J2 uses the
>standard servlet-api session support, so details of its operation can be
>widely found on the net and other print documentation.
>
>Just to be clear, session state is maintained by the servlet container,
>not J2.  In order to have an official "memory leak" problem, we have to
>show that the memory problem extends for much longer than the session
>timeout. To test this, one should use a much smaller session timeout,
>(say 1 minute vs. the standard 30 minutes). If the memory consumption
>occurs at a slower rate after changing the session timeout, it indicates
>that it is simply a session limit bound and not a "memory leak". If you
>get "Out Of Memory" exceptions, slow down your tests so that you can
>observe behavior relative to the session timeout interval.
>
>It is worth mentioning again: JVMs do not always use/return system
>memory in a way that reflects ACTUAL usage. You should be monitoring
>memory profiles using java.lang.Runtime freeMemory(), maxMemory(), and
>totalMemory() calls.
>
>Randy
>
>Sujit Menon wrote:
>
>  
>
>>Hi randy,
>>I have a similar scenario. the problem is the memory leakage is coming when we give
continuous hit to the server . Can you tell me how to implement jsessionid cookie?
>>
>>Regards
>>Sujit
>>-----Original Message-----
>>From: Randy Watler [mailto:watler@wispertel.net]
>>Sent: Friday, September 02, 2005 1:46 AM
>>To: Jetspeed Developers List
>>Subject: Re: Memory leakage in Jetspeed
>>
>>Sathish,
>>
>>You must implement JSESSIONID cookie handling in your stress/load tests
>>or you ARE creating a new session per request. Also, JVMs do not give
>>back memory until they feel it is necessary to do so... normally on
>>major collections and only if the JVM is run in "server" modes.
>>
>>We are more than willing to help substantiate your claims so that we can
>>fix the product if there is indeed a memory/session issue, but we more
>>details concerning the testing you are doing to make much more progress.
>>
>>Randy
>>
>>
>>Sathish Kannan wrote:
>>
>>
>>
>>    
>>
>>>Thanks.
>>>I am using Jetspeed2.
>>>
>>>I am not able to understand  "Are you returning either the JSESSIONID cookie or
;jsessionid in the url for subsequent requests?"
>>>
>>>How do I check this?
>>>
>>>We are not creating session for every request.  When user logs in session will
be created
>>>
>>>
>>>Thanks and Regards
>>>Sathish
>>>
>>>-----Original Message-----
>>>From: Santiago Gala [mailto:sgala@apache.org]
>>>Sent: Thursday, September 01, 2005 3:24 PM
>>>To: Jetspeed Developers List
>>>Subject: Re: Memory leakage in Jetspeed
>>>
>>>El jue, 01-09-2005 a las 15:05 +0530, Sathish Kannan escribió:
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>Hi
>>>>
>>>>I am getting some memory leakage when I run JetSpeed
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>Jetspeed 1 or 2? which version?
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>I have executed a shell script that uses curl and execute continues
>>>>multiple loading of the jetspeed page. For every page that is viewed,
>>>>there is a 40 to 50K memory leak that never appears to be freed up.
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>Are you returning either the JSESSIONID cookie or ;jsessionid in the url
>>>for subsequent requests?
>>>
>>>If not, each request will be starting a new session, which takes a fair
>>>amount of resources, and by default those resources won't be released
>>>until after it times out (30 minutes by default in tomcat). Tomcat
>>>manager can tell you how many sessions are active for a given webapp.
>>>
>>>Regards
>>>Santiago
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>Is it a known issue.
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>Thanks in advance
>>>>
>>>>Sathish
>>>>
>>>>---------------------------------------------------------------------------------------------
>>>>This message, including any attachments, contains confidential information
intended for a specific individual and purpose, and is intended for the addressee only. Any
unauthorized disclosure, use, dissemination, copying, or distribution of this message or any
of its attachments or the information contained in this e-mail, or the taking of any action
based on it, is strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail and delete this message.
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>--
>>>VP and Chair, Apache Portals (http://portals.apache.org)
>>>Apache Software Foundation
>>>--
>>>VP and Chair, Apache Portals (http://portals.apache.org)
>>>Apache Software Foundation
>>>
>>>---------------------------------------------------------------------------------------------
>>>This message, including any attachments, contains confidential information intended
for a specific individual and purpose, and is intended for the addressee only. Any unauthorized
disclosure, use, dissemination, copying, or distribution of this message or any of its attachments
or the information contained in this e-mail, or the taking of any action based on it, is strictly
prohibited. If you are not the intended recipient, please notify the sender immediately by
return e-mail and delete this message.
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>
>>>
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
>>---------------------------------------------------------------------------------------------
>>This message, including any attachments, contains confidential information intended
for a specific individual and purpose, and is intended for the addressee only. Any unauthorized
disclosure, use, dissemination, copying, or distribution of this message or any of its attachments
or the information contained in this e-mail, or the taking of any action based on it, is strictly
prohibited. If you are not the intended recipient, please notify the sender immediately by
return e-mail and delete this message.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>---------------------------------------------------------------------------------------------
>This message, including any attachments, contains confidential information intended for
a specific individual and purpose, and is intended for the addressee only. Any unauthorized
disclosure, use, dissemination, copying, or distribution of this message or any of its attachments
or the information contained in this e-mail, or the taking of any action based on it, is strictly
prohibited. If you are not the intended recipient, please notify the sender immediately by
return e-mail and delete this message.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message