Re: Potential reuse of TagHandlers implementing JspIdConsumer?

2008-12-12 Thread Jochen Wuttke

Hi,

I finally found the time to build a test case for this issue.
I attach the WAR, but you still need to put the runtime library of  
AspectJ (aspectjrt.jar) on the classpath when running Tomcat.
The behavior I observe is that whenever I load/reload the page, the  
JspIdConsumer objects get allocated, and some, but never all of

them get GC'd. You should see messages on the console/log like

Adding JspIdConsumer:someClassName:itsHashCode:theJspId

and

Removed someJspId

You will see three Adding messages for every instance created (it's  
a mess to track this properly),

and you should see one Removed message for every GC'd instance.
When I run grep | wc on the output, the distance between the number  
of created and GC'd object grows over time and reloads of the test page.
I had this running for a bit, trying to see if after a session timeout  
the remaining instances would be GC'd, but they didn't. I don't know  
what to make of this, but it feels like Tomcat is holding on to some  
of the instances for too long for no good reason.


Jochen


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Potential reuse of TagHandlers implementing JspIdConsumer?

2008-12-12 Thread Mark Thomas
Jochen Wuttke wrote:
 Hi,
 
 I finally found the time to build a test case for this issue.
 I attach the WAR,

The users list won't accept attachments. You;ll need to open a bugzilla
entry and attach your test case there.

Mark


 but you still need to put the runtime library of
 AspectJ (aspectjrt.jar) on the classpath when running Tomcat.
 The behavior I observe is that whenever I load/reload the page, the
 JspIdConsumer objects get allocated, and some, but never all of
 them get GC'd. You should see messages on the console/log like
 
 Adding JspIdConsumer:someClassName:itsHashCode:theJspId
 
 and
 
 Removed someJspId
 
 You will see three Adding messages for every instance created (it's a
 mess to track this properly),
 and you should see one Removed message for every GC'd instance.
 When I run grep | wc on the output, the distance between the number of
 created and GC'd object grows over time and reloads of the test page.
 I had this running for a bit, trying to see if after a session timeout
 the remaining instances would be GC'd, but they didn't. I don't know
 what to make of this, but it feels like Tomcat is holding on to some of
 the instances for too long for no good reason.
 
 Jochen
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Potential reuse of TagHandlers implementing JspIdConsumer?

2008-11-18 Thread Jochen Wuttke

Hi,

I'd like to bump this issue once more.
I finally had some time to run some more experiments to see what  
happens with TagHandlers that implement JspIdConsumer. My setup is  
Tomcat 6 + MyFaces + JSF CarDemo, and I'm using AspectJ to trace  
creation and garbage collection of objects implementing JspIdConsumer.  
My experiments indicate the following:


1. JspIdConsumer instances do NOT get garbage collected after a page  
has finished processing.
2. JspIdConsumer instances do NOT get garbage collected after a  
session times out.
3. SOME JspIdConsumer instances DO get garbage collected when a given  
JSP-generated page is reloaded or accessed in a different session.


To obtain these results I ran Tomcat with very little heap memory (it  
seems it starts fine with the 64M default), loaded the car demo in  
several browser sessions and ran through all the other JSP/Servlet  
examples that come with Tomcat to increase the memory consumption and  
trigger GC. Unfortunately I don't have the time and tools to do a  
proper stress test.
In any case, considering the specification of JspIdConsumer, which  
states that instances may never be reused, the caching of these  
instances as it is done in current JSPs is unnecessary, and since  
these instances don't seem to be GC'd, this seems to be a memory leak.


Could the developers confirm this or suggest what is going on that I'm  
missing?


Jochen Wuttke

---
PhD Candidate
Faculty of Informatics
University of Lugano
Via Giuseppe Buffi 13
CH-6904 Lugano - Switzerland

phone: +41 58 666 4308
www.inf.unisi.ch/phd/wuttke






-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Potential reuse of TagHandlers implementing JspIdConsumer?

2008-11-18 Thread Mark Thomas
Jochen Wuttke wrote:
 Hi,
 
 I'd like to bump this issue once more.
 I finally had some time to run some more experiments to see what happens
 with TagHandlers that implement JspIdConsumer. My setup is Tomcat 6 +
 MyFaces + JSF CarDemo, and I'm using AspectJ to trace creation and
 garbage collection of objects implementing JspIdConsumer. My experiments
 indicate the following:
 
 1. JspIdConsumer instances do NOT get garbage collected after a page has
 finished processing.
 2. JspIdConsumer instances do NOT get garbage collected after a session
 times out.
 3. SOME JspIdConsumer instances DO get garbage collected when a given
 JSP-generated page is reloaded or accessed in a different session.
 
 To obtain these results I ran Tomcat with very little heap memory (it
 seems it starts fine with the 64M default), loaded the car demo in
 several browser sessions and ran through all the other JSP/Servlet
 examples that come with Tomcat to increase the memory consumption and
 trigger GC. Unfortunately I don't have the time and tools to do a proper
 stress test.
 In any case, considering the specification of JspIdConsumer, which
 states that instances may never be reused, the caching of these
 instances as it is done in current JSPs is unnecessary, and since these
 instances don't seem to be GC'd, this seems to be a memory leak.
 
 Could the developers confirm this or suggest what is going on that I'm
 missing?

3 looks like a possible memory leak although I can't be certain with the
information provided here. A simple test case (that doesn't use JSF) would
help.

1  2 could just be poor recycling rather than a leak. Again, a test case
would help clarify this.

Mark



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Potential reuse of TagHandlers implementing JspIdConsumer?

2008-10-20 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jochen,

I'd definitely like to know the answer to this, too. Replying to bump
the topic.

- -chris

Jochen Wuttke wrote:
 Hi,
 
 for my research project I've been doing some ApsectJ magic with Tomcat
 and deployed WebApps. Among other things I'm interested in detecting at
 runtime when TagHandlers instantiated in a HttpServlet go out of scope.
 Since that can't be done with AspectJ I was tracking garbage collection
 to see when the objects get removed. To be sure that that made some
 sense I looked at where the servlet code instantiates the TagHandlers,
 and since they are created and used as local variables, I was expecting
 them to be collected after the servlet finishes processing.
 Unfortunately, a few experiments showed that that is not the case. 
 After delving into the details of the servlet code generated for JSP
 pages I discovered that the methods instantiating TagHandlers also store
 them in TagHandlerPools using #reuse().
 I'm doing my experiments with a demo application for Java Server Faces,
 and all JSF tag handler implement
 javax.servlet.jsp.tagext.JspIdConsumer. The spec says that handler
 implementing that interface may not be reused, so I was wondering if
 this is a potential bug or if I'm missing some intricate detail of how
 things work.
 
 Thanks,
 Jochen
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj8ivkACgkQ9CaO5/Lv0PBVxgCeMV3deLI4A+CtT+WY26+DLV3/
K7IAnR0nNeb29DYPoTf6V6M88HVeeojm
=rlNa
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Potential reuse of TagHandlers implementing JspIdConsumer?

2008-10-16 Thread Jochen Wuttke

Hi,

for my research project I've been doing some ApsectJ magic with Tomcat  
and deployed WebApps. Among other things I'm interested in detecting  
at runtime when TagHandlers instantiated in a HttpServlet go out of  
scope. Since that can't be done with AspectJ I was tracking garbage  
collection to see when the objects get removed. To be sure that that  
made some sense I looked at where the servlet code instantiates the  
TagHandlers, and since they are created and used as local variables, I  
was expecting them to be collected after the servlet finishes  
processing.
Unfortunately, a few experiments showed that that is not the case.   
After delving into the details of the servlet code generated for JSP  
pages I discovered that the methods instantiating TagHandlers also  
store them in TagHandlerPools using #reuse().
I'm doing my experiments with a demo application for Java Server  
Faces, and all JSF tag handler implement  
javax.servlet.jsp.tagext.JspIdConsumer. The spec says that handler  
implementing that interface may not be reused, so I was wondering if  
this is a potential bug or if I'm missing some intricate detail of how  
things work.


Thanks,
Jochen

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]