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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
