Hi, that is absolutely great patch, reduces number of javassist instances to one for each type, thank you for your quick response!
Martin Gurkan Erdogdu píše v So 14. 08. 2010 v 00:41 -0700: > I have corrected issue with https://issues.apache.org/jira/browse/OWB-438. > > > Could you try again with TRUNK? > > > --Gurkan > > > ________________________________ > From: Gurkan Erdogdu <[email protected]> > To: [email protected] > Sent: Sat, August 14, 2010 10:10:45 AM > Subject: Re: [DISCUSSION] javassist-3.12 > > I have looked in detail. This is a bug, please open a JIRA issue. Patch is > welcome :) > > > We forget to add cache instance that is resolved in > BeanManagerImpl#getReference > > > Thanks; > > --Gurkan > > > ________________________________ > From: Martin Koci <[email protected]> > To: [email protected] > Sent: Fri, August 13, 2010 11:47:08 PM > Subject: Re: [DISCUSSION] javassist-3.12 > > Update: > > it's not a memory leak. After abortion of tests _javassist_ instances > are GCed. > > But after few hours of running tests against real application (migrated > from Spring to CDI/OWB) JVM heap contains *millions* of __javassist__ > instances. This situation depends on GC settings and JVM is probably > stressed too much to GC them effectively. > > > 99% of _javassist_ allocations comes from WebBeansELResolver.getValue -> > WebBeansELResolver.getNormalScopedContextualInstance. Is it really > nessesary to resolve EL expression to proxies? Is CDI specification so > strict? If it is, is there a workaround? > > If I compare Spring based solution with CDI based there is a big > performance degradation. In Spring if <bean id="sampleBean" > class="sampleBean" scope="session"> is used, bean is created in > httpSession instance. Then ELResolver find it in session and simply > returns it. There is no proxy, because bean is not injected. > > But with OWB: > > 1) bean is not in httpSession object -> ELResolver.getvalue goes thru > resolvers chain and finally WebBeansELResolver resolves it > > 2) WebBeansELResolver creates a new proxy instance (one for request ?) > and returns it as result of resolving. > > > But if we have many managed bean in view there is a problem: consider 10 > @SessionScope @Named used in one JSF view. One request to this view > creates 10 proxy instances. 100 concurrent users create 1000 instances > per one request. Yes, those instances can be GCed but it cost some time > and memory. Now compare this with Spring: with Spring there is no new > objects allocation per request (except the first one) and ELResolver > resolves it more quickly. > > Am I missing something or is it a real and known problem? I don't know > much about CDI yet so please correct me I am wrong. > > > > Many thanks, > > > Martin Kočí > > > > > > Martin Koci píše v Pá 13. 08. 2010 v 21:42 +0200: > > Hi, > > > > I do some stress tests and memory leak detector shows that number of > > _javassist_ instances is growing very fast. With this simple use case: > > > > @SessionScoped @Named public class SampleBean {} > > > > and in JSF page: > > > > <h:outputText value="#{sampleBean}" /> > > <h:commandButton value="submit" /> > > > > > > With simulated 30 concurrent users (jmeter) and few minutes of running > > java heap contains thousands instances SampleBean_javasssist_. After one > > hour it is over one milion. First I thought that this is memory leak in > > javassist as discussed id this mail thread but I use > > javassist-3.12.1.GA.jar > > > > Any ideas? > > > > Thanks, > > > > Martin Kočí > > > > > > Gurkan Erdogdu píše v Po 28. 06. 2010 v 22:45 -0700: > > > Hello Mark; > > > > > > What is the release of alpha-1? I think we were little late :) > > > > > > > > > Thanks; > > > > > > --Gurkan > > > > > > > > > ________________________________ > > > From: Mark Struberg <[email protected]> > > > To: [email protected] > > > Sent: Wed, June 23, 2010 5:02:34 PM > > > Subject: [DISCUSSION] javassist-3.12 > > > > > > Hoi! > > > > > > Since javassist-3.11 has quite remarkable mem leaks, we should use > >javassist-3.12 for our RC1 (or -alpha-1) release. > > > > > > The problem is that javassist-3.12 is still not uploaded to > > > maven.central. > >Pete and Andrew Dinn are working on that but it will most probably take a > >few > >further weeks since Pete is not available atm (JBoss world, etc). > > > > > > The release is available on the public jboss edge maven repo: > > > > > > http://repository.jboss.org/maven2-brew > > > > > > Wdyt, should we use this repo or should we continue delivering with > >javassist-3.11 for now and upgrade to 3.12 later? > > > > > > We can also write in our README that we know about the mem leaks and that > >people should upgrade to 3.12 theirselfs if needed. > > > > > > LieGrue, > > > strub > > > > > > > > > >
