Hiho! There are a few observations
1.) Spring will need to use proxies for EL soon too. Since with EL-2.2 it's possible to use those resolved beans and pass them as parameter to some other method via EL. And this method might need to use a proxy. Going via direct instances will work in 99.8%, but the 0.2% will kill your app. If we find a way to detect such cases easily, then we might use contextual instances too. But I honestly doubht it. 2.) we do already cache our resolved proxies once per Request in the ELResolver. The performance is pretty ok. Of course not as good as if we would take the contextual instances directly, but not really much worse. On a typical medium sized JSF page it costs about 1ms. And even on my biggest page which has about 1300 lines in a h:dataTable all the page processing is done in 350ms. 3.) Caching proxies in general might be applicable but closes the ability to implement caching in the proxy itself. (Which we currently don't do extensively). So the possible side effects might not pay off... LieGrue, strub ----- Original Message ---- > From: Martin Koci <[email protected]> > To: [email protected] > Sent: Fri, August 13, 2010 10: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 > > > > > > > > > > > >
