RE: Are threaded services building up CtClass instances in the ja vassist ClassPool?

["Hensley, Richard" <Ri...@McKesson.com>]

Here is a patch that at least shows that the CtClasses are hanging out in
the pool.

Index: framework/src/test/org/apache/hivemind/service/impl/TestClassFab.java
===================================================================
RCS file:
/home/cvspublic/jakarta-hivemind/framework/src/test/org/apache/hivemind/serv
ice/impl/TestClassFab.java,v
retrieving revision 1.5
diff -u -r1.5 TestClassFab.java
--- framework/src/test/org/apache/hivemind/service/impl/TestClassFab.java
6 Jan 2005 01:45:10 -0000	1.5
+++ framework/src/test/org/apache/hivemind/service/impl/TestClassFab.java
19 May 2005 17:31:17 -0000
@@ -27,11 +27,13 @@
 import java.util.zip.DataFormatException;
 
 import javassist.CtClass;
+import javassist.NotFoundException;
 import junit.framework.AssertionFailedError;
 
 import org.apache.hivemind.ApplicationRuntimeException;
 import org.apache.hivemind.impl.BaseLocatable;
 import org.apache.hivemind.service.ClassFab;
+import org.apache.hivemind.service.ClassFabUtils;
 import org.apache.hivemind.service.MethodFab;
 import org.apache.hivemind.service.MethodSignature;
 import org.apache.hivemind.test.HiveMindTestCase;
@@ -46,6 +48,8 @@
 public class TestClassFab extends HiveMindTestCase
 {
     private CtClassSource _source;
+    
+    private HiveMindClassPool _pool;
 
     protected void setUp() throws Exception
     {
@@ -53,11 +57,11 @@
 
         ClassLoader threadLoader =
Thread.currentThread().getContextClassLoader();
 
-        HiveMindClassPool pool = new HiveMindClassPool();
+        _pool = new HiveMindClassPool();
 
-        pool.appendClassLoader(threadLoader);
+        _pool.appendClassLoader(threadLoader);
 
-        _source = new CtClassSource(pool);
+        _source = new CtClassSource(_pool);
     }
 
     private ClassFab newClassFab(String className, Class superClass)
@@ -67,6 +71,22 @@
         return new ClassFabImpl(_source, ctClass);
     }
 
+    public void testPoolBuildup() throws NotFoundException 
+    {
+        String firstGeneratedName = ClassFabUtils
+            .generateClassName(Runnable.class);
+        ClassFab cf = newClassFab(firstGeneratedName, Object.class);
+        cf.getClass();
+        try {
+            _pool.get(firstGeneratedName);
+            unreachable();
+        }
+        catch (NotFoundException ne) {
+            // expected
+        }
+    }
+
+    
     public void testCreateBean() throws Exception
     {
         ClassFab cf = newClassFab("TargetBean", Object.class); 

-----Original Message-----
From: Hensley, Richard 
Sent: Thursday, May 19, 2005 9:54 AM
To: 'hivemind-dev@jakarta.apache.org'
Subject: Are threaded services building up CtClass instances in the
javassist ClassPool?

I've been reviewing how javassist works, and a passage in the documentation
struck me as interesting. In short, it says that any CtClass created in the
javassist ClassPool stays in the pool forever. 

Now that got me thinking about how Hivemind uses javassist for threaded
services. If I read the code correctly, the TheadedServiceModel creates an
inner and outer proxy class with a unique name that implements the service
interface each time the service is instantiated. Upon reflection, I'm
wondering aloud if this is a potential memory leak. 

The specific thing that has me concerned is Tapestry 4.0 use of Thread
services for things like HttpServletRequest and HttpServletResponse. After
thousands of hits to the web application, would the javassist have a toxic
build up of CtClass instances?

If this is happening, it is a memory leak that could really cause a problem
for long running web applications.

I will see if I can prove or disprove my thesis later today.

There are good reasons for javassist keeping CtClass instances around,
however I'm not sure the reasons apply to Hivemind. We might be able to get
around a potential memory leak by simply detaching the Hivemind CtClass
instances from the javassist ClassPool after a class has been instantiated.
The CtClass instances are left in the pool so that future CtClass
manipulations can reference the new classes. I don't think Hivemind needs
this.

By the way, this would apply to the Singleton and Pooled models also, but
services using these models are long lived so new CtClasses are not created
very often for services that use these models.

I don't think this applies to the Primitive model.

Richard


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