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 > > > > >
