No Leo, cannot be a problem! As Gerhard already explained we only keep a configurable number of 'windows' per Session. Once this limit is exceeded the LRU one will get destroyed. It's really a non-issue. The problem Andreas faces must be another one. Or it's a bug, but this is really well tested imo.
LieGrue, strub ----- Original Message ----- > From: Leonardo Uribe <lu4...@gmail.com> > To: MyFaces Discussion <users@myfaces.apache.org> > Cc: > Sent: Friday, November 30, 2012 5:47 AM > Subject: Re: CODI: Exclude windowId from certain pages > > Hi > > Are you invalidating the session (logout) in some point? Maybe that could be > related to the problem, because if you keep the session active and create > hundreds of different windows, since the session is not released that memory > will not be restored and the stress testing will not be accurate (or > realistic). > > regards, > > Leonardo Uribe > > 2012/11/29 Gerhard Petracek <gerhard.petra...@gmail.com>: >> hi andreas, >> >> please have a look at WindowContextConfig - see e.g. >> #isUnknownWindowIdsAllowed and #getMaxWindowContextCount >> -> it shouldn't be an issue (since you can customize the default > behaviour). >> >> btw: >> we are doing a lot of such tests (without windowId=automatedEntryPoint) and >> never saw an issue - but we don't use glassfish ;) >> >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF/JavaEE powerhouse - >> JavaEE Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> 2012/11/29 Andreas Kaiser <kaiser.andr...@gmail.com> >> >>> Hi >>> thanks for the answer >>> >>> I will have a look at this. >>> BTW. it seems that the the windowId is a potential security issue. >>> >>> For instance call a side with an unknown windowId. CODI will generate a > new >>> valid one. Just change the generated one to a new invalid id. CODI will >>> generate a new one again. Repeat this until you are out of ids or the >>> server is out of memory ;-) >>> >>> This is whats happend in my application due to stress testing >>> >>> Regards >>> >>> >>> On Thu, Nov 29, 2012 at 11:03 PM, Gerhard Petracek < >>> gerhard.petra...@gmail.com> wrote: >>> >>> > hi andreas, >>> > >>> > first of all: welcome @ myfaces! >>> > >>> > there are different approaches - e.g. you can use urls with >>> > windowId=automatedEntryPoint >>> > (see the javadoc in WindowContextManager) >>> > >>> > regards, >>> > gerhard >>> > >>> > http://www.irian.at >>> > >>> > Your JSF/JavaEE powerhouse - >>> > JavaEE Consulting, Development and >>> > Courses in English and German >>> > >>> > Professional Support for Apache MyFaces >>> > >>> > >>> > >>> > 2012/11/29 Andreas Kaiser <kaiser.andr...@gmail.com> >>> > >>> > > Hi everybody >>> > > >>> > > I have following setup : >>> > > >>> > > Glassfish 3.1.2.2 >>> > > Weld >>> > > Java EE6 + JSF + CDI + JPA >>> > > CODI: 1.0.5 >>> > > >>> > > My problem: >>> > > >>> > > We use and like the windowId Feature from CODI. But it causes > some big >>> > > problems on some pages which are specially created for stress > testing. >>> > > >>> > > These pages are accessed from 500+ clients generated from > JMeter. >>> > > Every client acts as a own browser. >>> > > >>> > > This pages (RequestScoped) can be accessed without login. > Therefore >>> CODI >>> > > generates a new windowId for every client. >>> > > >>> > > The problem is that the JMeter tests run multiple times. Due > to this >>> the >>> > > Hashmap in JSFWindowContext.java consums a lot of memory > until the >>> > > Glassfish has no space left which leads into a 100 % CPU > usage because >>> > the >>> > > garbage collector tries to free a even the last few bytes. >>> > > >>> > > My question is >>> > > 1. Is it possible to create windowIds only a user is logged > in >>> > > 2. Is there an option to change the default behavior >>> > > 3. Can i exclude some pages being handled by the codi > JSFWindowManager >>> > > >>> > > >>> > > >>> > > >>> > > Regards >>> > > >>> > >>> >
