Re: [Resin-interest] Possible memory leak in Resin 4.0.9
I'll tried to do so. 2010/8/20 Scott Ferguson : > Wesley Wu wrote: >> 2010/8/20 Scott Ferguson : >> >>> I still think there's a chance for a Resin leak; I just don't understand >>> where it's coming from. >>> >> >> I think so. The same code worked fine (no leak) in Resin 4.0.5. >> > > Do you have access to the eclipse "mat" program or some other heap > analyzer? > > If you can reproduce the issue, ask Resin to dump the heap (it's in > /resin-admin/memory with the jvm heap dump button), and then ask the > heap analyzer to trace the leaking memory to root, it would help track > down this issue greatly. > > -- Scott >> >>> It shouldn't matter what context you're injecting from, as long as >>> you're creating a new top-level CreationalContext. The getReference for >>> a dependent bean shouldn't have any references to it. >>> >>> -- Scott >>> >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Wesley Wu wrote: > 2010/8/20 Scott Ferguson : > >> I still think there's a chance for a Resin leak; I just don't understand >> where it's coming from. >> > > I think so. The same code worked fine (no leak) in Resin 4.0.5. > Do you have access to the eclipse "mat" program or some other heap analyzer? If you can reproduce the issue, ask Resin to dump the heap (it's in /resin-admin/memory with the jvm heap dump button), and then ask the heap analyzer to trace the leaking memory to root, it would help track down this issue greatly. -- Scott > >> It shouldn't matter what context you're injecting from, as long as >> you're creating a new top-level CreationalContext. The getReference for >> a dependent bean shouldn't have any references to it. >> >> -- Scott >> > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
2010/8/20 Scott Ferguson : > I still think there's a chance for a Resin leak; I just don't understand > where it's coming from. I think so. The same code worked fine (no leak) in Resin 4.0.5. > > It shouldn't matter what context you're injecting from, as long as > you're creating a new top-level CreationalContext. The getReference for > a dependent bean shouldn't have any references to it. > > -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Wesley Wu wrote: > Hi Scott, > > I believe I've fixed this issue by adding @ApplicationScoped and > @RequestedScoped annotation to my beans. :) > I still think there's a chance for a Resin leak; I just don't understand where it's coming from. It shouldn't matter what context you're injecting from, as long as you're creating a new top-level CreationalContext. The getReference for a dependent bean shouldn't have any references to it. -- Scott > Thanks for your efforts. > > -Wesley > > 2010/8/18 Wesley Wu : > >> Hi Scott, >> >> Thanks for the checking. >> >> Today I double checked the CDI spec and got some new knowledge. >> >> Nearly all my beans were not annotated with any scope, so that they >> should be @Dependent. >> >> Some of the beans were created (not injected) in a servlet filter via >> a static ObjectFactory. >> I think the beans should be transient but they are NOT. >> >> They actually were probably immortal because they were created in a >> servlet filter (singleton in webapp). >> And also my ObjectFactory was annotated with @Singleton too, too bad. >> >> As a workaround, I may annotated most my beans as @ApplicationScoped >> or @SessionScoped, >> because they're all stateless. At least after a bean was annotated as >> @SessionScoped, the >> @PreDestroy method was correctly fired when the request ended. >> >> This workaround SHOULD address the memory leak problem of my site, >> though not thoroughly tested. >> >> >> It's my initial thought. Hope you have a full story to tell me, if >> u've got some time. :) >> >> Thanks again. >> >> -Wesley >> >> > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, I believe I've fixed this issue by adding @ApplicationScoped and @RequestedScoped annotation to my beans. :) Thanks for your efforts. -Wesley 2010/8/18 Wesley Wu : > Hi Scott, > > Thanks for the checking. > > Today I double checked the CDI spec and got some new knowledge. > > Nearly all my beans were not annotated with any scope, so that they > should be @Dependent. > > Some of the beans were created (not injected) in a servlet filter via > a static ObjectFactory. > I think the beans should be transient but they are NOT. > > They actually were probably immortal because they were created in a > servlet filter (singleton in webapp). > And also my ObjectFactory was annotated with @Singleton too, too bad. > > As a workaround, I may annotated most my beans as @ApplicationScoped > or @SessionScoped, > because they're all stateless. At least after a bean was annotated as > @SessionScoped, the > @PreDestroy method was correctly fired when the request ended. > > This workaround SHOULD address the memory leak problem of my site, > though not thoroughly tested. > > > It's my initial thought. Hope you have a full story to tell me, if > u've got some time. :) > > Thanks again. > > -Wesley > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, Thanks for the checking. Today I double checked the CDI spec and got some new knowledge. Nearly all my beans were not annotated with any scope, so that they should be @Dependent. Some of the beans were created (not injected) in a servlet filter via a static ObjectFactory. I think the beans should be transient but they are NOT. They actually were probably immortal because they were created in a servlet filter (singleton in webapp). And also my ObjectFactory was annotated with @Singleton too, too bad. As a workaround, I may annotated most my beans as @ApplicationScoped or @SessionScoped, because they're all stateless. At least after a bean was annotated as @SessionScoped, the @PreDestroy method was correctly fired when the request ended. This workaround SHOULD address the memory leak problem of my site, though not thoroughly tested. It's my initial thought. Hope you have a full story to tell me, if u've got some time. :) Thanks again. -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Wesley Wu wrote: > Hi Scott, > > The memory leak circumstance was not spotted in Resin 4.0.5 and early > 4.0.x versions. > > One of the inject path is: > > * A filter CmsPageFilter dispatch a request to a Jsp page through > javax.servlet.RequestDispatcher.forward(request, response) > * Jsp page called a BeanMethod custom jsp tag > * The jsp tag create a VideoManager through my BeanManager wrapper > (MDIObjectFactory) > * VideoManager injects a PersonManager > * PersonManager injects a PersonController > * PersonController injects a DefaultBeanManager and a DefaultBeanReader > * DefaultBeanManager and DefaultBeanReader inject a > CmsPersistentUnit(@Singleton) > * CmsPersistentUnit injects a javax.persistence.EntityManagerFactory > (@PersistenceUnit) > > All those beans except CmsPersistentUnit were dependent scoped (not > explicitly annotated) > and should be created at its inject point and freed when > the parent bean (the jsp page) was destroyed. > Just double-checking, which of the beans have which scope annotations? I just verified that the basic getReference with dependent scope isn't leaking so there must be some non-dependent bean that's triggering the problem. -- Scott > I list three most frequently bean creation process here. > > #handle jsp tag which requires bean creation=== > # this call should be the creation of an @Dependent (thought not > explicitly annotated) beans > # like com.buysou.cms.managers.DefaultBeanManager or > com.buysou.cms.managers.DefaultBeanReader > # (for writing/reading database through a @RequestScoped @PersistentContext) > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)118 > com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, > CreationalContext)117 > com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) > 117 > com.caucho.config.inject.InjectionTargetBuilder.inject(Object, > CreationalContext)117 > com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) > 117 > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)117 > com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, > CreationalContext)114 > com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) > 114 > com.caucho.config.inject.InjectionTargetBuilder.inject(Object, > CreationalContext)114 > com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) > 114 > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)114 > com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, > CreationalContext)112 > com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) > 112 > com.caucho.config.inject.InjectionTargetBuilder.inject(Object, > CreationalContext)112 > com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) > 111 > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)111 > com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, > CreationalContext)103 > com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) > 103 > com.caucho.config.inject.InjectionTargetBuilder.inject(Object, > CreationalContext)103 > com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) > 103 > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)103 > com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, > CreationalContext)89 > com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) > 89 > com.caucho.config.inject.InjectionTargetBuilder.inject(Object, > CreationalContext)89 > com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) > 88 > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)88 > com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, > CreationalContext)60 > com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) > 60 > com.caucho.config.inject.InjectionTargetBuilder.inject(Object, > CreationalContext)60 > com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) > 58 > com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, > CreationalContextImpl, InjectionPoint)58 > com.caucho.config.inject.InjectionTargetBu
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
My BeanManager wrapper code
@Singleton
@Startup
public class MDIObjectFactory {
private static BeanManager beanManager;
private static BeanManager getBeanManager() {
if (beanManager == null) {
try {
InitialContext ic = new InitialContext();
beanManager = (BeanManager)
ic.lookup("java:comp/BeanManager");
} catch (Exception e) {
throw new RuntimeException(e);
}
}
return beanManager;
}
...
public T buildBean(Class beanClass) {
Named named = beanClass.getAnnotation(Named.class);
if (named != null) {
Bean bean = (Bean)
beanManager.resolve(beanManager.getBeans(named.value()));
CreationalContext env =
beanManager.createCreationalContext(bean);
return (T) beanManager.getReference(bean,
bean.getBeanClass(), env);
}
Bean bean = (Bean)
beanManager.resolve(beanManager.getBeans(beanClass));
CreationalContext env =
beanManager.createCreationalContext(bean);
return (T) beanManager.getReference(bean, beanClass, env);
}
public Object buildBean(String beanName) {
Bean bean = beanManager.resolve(beanManager.getBeans(beanName));
CreationalContext env =
beanManager.createCreationalContext(bean);
return beanManager.getReference(bean, bean.getBeanClass(), env);
}
...
}
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, The memory leak circumstance was not spotted in Resin 4.0.5 and early 4.0.x versions. One of the inject path is: * A filter CmsPageFilter dispatch a request to a Jsp page through javax.servlet.RequestDispatcher.forward(request, response) * Jsp page called a BeanMethod custom jsp tag * The jsp tag create a VideoManager through my BeanManager wrapper (MDIObjectFactory) * VideoManager injects a PersonManager * PersonManager injects a PersonController * PersonController injects a DefaultBeanManager and a DefaultBeanReader * DefaultBeanManager and DefaultBeanReader inject a CmsPersistentUnit(@Singleton) * CmsPersistentUnit injects a javax.persistence.EntityManagerFactory (@PersistenceUnit) All those beans except CmsPersistentUnit were dependent scoped (not explicitly annotated) and should be created at its inject point and freed when the parent bean (the jsp page) was destroyed. I list three most frequently bean creation process here. #handle jsp tag which requires bean creation=== # this call should be the creation of an @Dependent (thought not explicitly annotated) beans # like com.buysou.cms.managers.DefaultBeanManager or com.buysou.cms.managers.DefaultBeanReader # (for writing/reading database through a @RequestScoped @PersistentContext) com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 118 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 117 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 117 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 117 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 117 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 117 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 114 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 114 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 114 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 114 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 114 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 112 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 112 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 112 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 111 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 111 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 103 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 103 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 103 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 103 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 103 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 89 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 89 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 89 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 88 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 88 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 60 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 60 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 60 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 58 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalContextImpl, InjectionPoint) 58 com.caucho.config.inject.InjectionTargetBuilder$FieldInjectProgram.inject(Object, CreationalContext) 34 com.caucho.config.inject.CandiProducer.inject(Object, CreationalContext) 34 com.caucho.config.inject.InjectionTargetBuilder.inject(Object, CreationalContext) 34 com.caucho.config.inject.ManagedBeanImpl.createDependent(CreationalContext) 33 com.caucho.config.inject.InjectManager$DependentReferenceFactoryImpl.create(CreationalContextImpl, CreationalConte
Re: [Resin-interest] Possible memory leak in Resin 4.0.9
Wesley Wu wrote: > Hi Scott, > > I've applied the 4.0.10 snapshot and the Alarm issue went away. Thanks. > > But Resin consumed all memory after certain hours and resulted in a > halt or restart. > > I did a jrockit flight recording and found there was a slow heap > increase during various GCs. > > The recording file shows the objects in heap order by total size > occupied descending as below: > > Class InstancesSize(bytes) Percentage%(%) > > com.caucho.config.inject.DependentCreationalContext 48,722,158 > 1,559,109,040 49.08 > com.buysou.cms.managers.DefaultBeanManager11,970,792 287,299,020 > 9.044 > com.buysou.cms.managers.DefaultBeanReader 14,126,509 226,024,144 > 7.115 > com.buysou.cms.utils.reflection.GenericReflectionProvider 11,970,802 > 191,532,840 6.029 > char[]1,792,936 160,800,482 5.062 > (others omitted) > > Obviously the DependentCreationalContext eat up the heap. > > Note: > > DefaultBeanManager & DefaultBeanReader & GenericReflectionProvider are > non singleton beans > which were injected into other beans at Dependent context (should be > GCed when request ends). > > Any ideas? > I'll check. Do you know what the path to root is for those objects? -- Scott > -Wesley > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Possible memory leak in Resin 4.0.9
Hi Scott, I've applied the 4.0.10 snapshot and the Alarm issue went away. Thanks. But Resin consumed all memory after certain hours and resulted in a halt or restart. I did a jrockit flight recording and found there was a slow heap increase during various GCs. The recording file shows the objects in heap order by total size occupied descending as below: Class InstancesSize(bytes) Percentage%(%) com.caucho.config.inject.DependentCreationalContext 48,722,158 1,559,109,040 49.08 com.buysou.cms.managers.DefaultBeanManager 11,970,792 287,299,020 9.044 com.buysou.cms.managers.DefaultBeanReader 14,126,509 226,024,144 7.115 com.buysou.cms.utils.reflection.GenericReflectionProvider 11,970,802 191,532,840 6.029 char[] 1,792,936 160,800,482 5.062 (others omitted) Obviously the DependentCreationalContext eat up the heap. Note: DefaultBeanManager & DefaultBeanReader & GenericReflectionProvider are non singleton beans which were injected into other beans at Dependent context (should be GCed when request ends). Any ideas? -Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
