From users-return-60359-apmail-myfaces-users-archive=myfaces.apache.org@myfaces.apache.org Fri Nov 30 16:01:41 2012 Return-Path: X-Original-To: apmail-myfaces-users-archive@www.apache.org Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 57974D584 for ; Fri, 30 Nov 2012 16:01:41 +0000 (UTC) Received: (qmail 16167 invoked by uid 500); 30 Nov 2012 16:01:40 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 15816 invoked by uid 500); 30 Nov 2012 16:01:33 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 15754 invoked by uid 99); 30 Nov 2012 16:01:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Nov 2012 16:01:31 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lu4242@gmail.com designates 209.85.160.53 as permitted sender) Received: from [209.85.160.53] (HELO mail-pb0-f53.google.com) (209.85.160.53) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Nov 2012 16:01:26 +0000 Received: by mail-pb0-f53.google.com with SMTP id jt11so484658pbb.12 for ; Fri, 30 Nov 2012 08:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=GwEZ/jmFGPN/UCqi7829gYajgozpSTnWNq2yuBOEP0Q=; b=ONcGn7neCj6WDtiCYUEBvbt6DpUyaaOZAvaiPBRy5NK7ixVR32Xd5/3j/n0rNo2c1i i0bnhAfqoKZ1TqwY2zYUY2AamvopjZnsJDLSJDomgEjeFhC8IKqw3y9pb+SHP6peDL3w 5vmuGJCa+g66BYnAcWw8nCNqd5Khu0KaQwZKpM1972szMJhzl5T0wC6IEG4EqEJ1+QQa avSRecrTSpfQqzYMebzoay/G8aSvfjqyCPdVCtI9MUYQjpGNRwxYiFRc6KxfjEMec9j4 j0KPIc45Yx7U204ydYqQnHyjFfiOlOgsf/adnJziEwmnKXySnJKWj/2/6MA1ysUPG4pn 8I9w== MIME-Version: 1.0 Received: by 10.68.234.201 with SMTP id ug9mr6760289pbc.63.1354291266745; Fri, 30 Nov 2012 08:01:06 -0800 (PST) Received: by 10.66.220.41 with HTTP; Fri, 30 Nov 2012 08:01:06 -0800 (PST) In-Reply-To: <1354272373.88774.YahooMailNeo@web28906.mail.ir2.yahoo.com> References: <1354259973.91725.YahooMailNeo@web28901.mail.ir2.yahoo.com> <1354272373.88774.YahooMailNeo@web28906.mail.ir2.yahoo.com> Date: Fri, 30 Nov 2012 11:01:06 -0500 Message-ID: Subject: Re: CODI: Exclude windowId from certain pages From: Leonardo Uribe To: MyFaces Discussion , Mark Struberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi 2012/11/30 Mark Struberg : > > > Well, then the problem is not the number of windows but the number of ses= sions ;) > Ok, good to know that. > In pure tomcat you can either restrict that or 'offload' them via a confi= guration. There are SessionManagers which keep n Sessions in memory and if = this number gets exceeded the LRU ones will get persisted to the file syste= m. That way it's almost impossible to trash the Sessions in pure tomcat. > > I have no clue what GlassFish does to prevent this scenario, but this is = for sure not a MyFaces, nor a CDI, nor a CODI problem ;) > Yes, I agree with you that is not a problem in MyFaces Core or CODI. But I have an "academic" doubt about CDI (in this case Weld). In theory, to enable session failover with Openwebbeans you have to add a file in src/main/resources called META-INF/openwebbeans/openwebbeans.properties and put a filter, so when the session is restored from the filesystem, it will be done correctly, and when the session is persisted, the window contexts in memory are released. OpenWebBeansFailover org.apache.webbeans.web.failover.FailOverFilter OpenWebBeansFailover Faces Servlet This works just perfect, but does Weld requires something similar? Sorry, i= f this question is trivial, obvious or off the topic. regards, Leonardo Uribe > LieGrue, > strub > > > > > >>________________________________ >> From: Andreas Kaiser >>To: MyFaces Discussion >>Sent: Friday, November 30, 2012 10:24 AM >>Subject: Re: CODI: Exclude windowId from certain pages >> >>Hi >> >>thanks for all answers. I will try to reduce the number of windows per >>session. >> >>Also i will try to change my stress test script to be a bit more gently t= o >>my server ( clean login and logout ) >> >>BTW. the number of ids is not 500*64 its NumberOfThreadsInJMeter * >>LoopCount >> >>in my case 500 * 200 =3D 100000 ( * bytesPerHashMapEntry ) >> >>The windows per session limitation will not work in this scenario because >>each request gets a new session >> >>Regards >> >> >>On Fri, Nov 30, 2012 at 8:26 AM, Leonardo Uribe wrote: >> >>> Anyway, you can only solve the question trying to reduce the param and = see >>> what happens. 500*64 is a big number. >>> On Nov 30, 2012 2:20 AM, "Mark Struberg" wrote: >>> >>> > 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 g= et >>> > 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 >>> > > To: MyFaces Discussion >>> > > 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 th= at >>> > memory >>> > > will not be restored and the stress testing will not be accurate (o= r >>> > realistic). >>> > > >>> > > regards, >>> > > >>> > > Leonardo Uribe >>> > > >>> > > 2012/11/29 Gerhard Petracek : >>> > >> 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=3DautomatedEntryPoint) 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 >>> > >> >>> > >>> Hi >>> > >>> thanks for the answer >>> > >>> >>> > >>> I will have a look at this. >>> > >>> BTW. it seems that the the windowId is a potential security issu= e. >>> > >>> >>> > >>> 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. CO= DI >>> > will >>> > >>> generate a new one again. Repeat this until you are out of ids o= r >>> 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.petracek@gmail.com> wrote: >>> > >>> >>> > >>> > hi andreas, >>> > >>> > >>> > >>> > first of all: welcome @ myfaces! >>> > >>> > >>> > >>> > there are different approaches - e.g. you can use urls with >>> > >>> > windowId=3DautomatedEntryPoint >>> > >>> > (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 >>> > >>> > >>> > >>> > > 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 cause= s >>> > > some big >>> > >>> > > problems on some pages which are specially created for stres= s >>> > > 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 >>> > >>> > > >>> > >>> > >>> > >>> >>> > > >>> > >>> >> >> >>