You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Andreas Kaiser <ka...@gmail.com> on 2012/11/29 20:37:06 UTC
CODI: Exclude windowId from certain pages
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
Re: CODI: Exclude windowId from certain pages
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
MyFaces has two web config params to limit the number of views in session:
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION (default 20)
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION
With the improvements done in MyFaces over PSS algorithm , there is no
need to worry about the view state anymore, because most of the time the
size of the beans is many times bigger than the information stored into
session by view state (MyFaces PSS is really good), even for simple
applications.
In CODI there is something similar to limit the number of available contexts
per session. See:
http://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/core/api/src/main/java/org/apache/myfaces/extensions/cdi/core/api/scope/conversation/config/WindowContextConfig.java
getMaxWindowContextCount (default 64)
It depends on how the beans are used. In my opinion, from performance
perspective is better to use request scope beans and use other scope
beans (window, view or view access) to hold only the necessary
information, to keep state size (and in that way memory usage) low.
It is true that request scoped beans needs to be created over and over,
but the jvm is quite fast doing that, so at the end it is better, and with
more memory available, less cpu are used because gc works better.
In my opinion, have a lot of objects in memory for a long time and then
discard them becomes detrimental for performance (but it depends).
In this case, I think try to reduce maxWindowContextCount is the
first option and if that doesn't work, check if the application is overusing
window, view, conversation or view access beans. I don't see a
fundamental problem in CODI or in JSF from performance perspective.
regards,
Leonardo Uribe
2012/11/30 Howard W. Smith, Jr. <sm...@gmail.com>:
> I think I've seen this discussed in this forum within the last few months
> (I might be wrong though).
>
> Anyway, I remember a similar topic and a solution, but it wasn't a CODI
> solution; this may or may not be related/solution.
>
> Quote from http://stackoverflow.com/a/5475564/933054
>
> *Until what point in time does JSF save the state of UI components on the
> server side and when exactly is the UI component's state information
> removed from the server memory?*
>
> Those two questions seem to boil down to the same. Anyway, this is
> implementation specific and also dependent on whether the state is saved on
> server or client. A bit decent implementation will remove it when it has
> been expired or when the queue is full. Mojarra for example has a default
> limit of 15 views when state saving is set to session. This is
> configureable with the following context param in web.xml:
>
> <context-param>
> <param-name>com.sun.faces.numberOfViewsInSession</param-name>
> <param-value>15</param-value></context-param>
>
>
>
>
>
> On Thu, Nov 29, 2012 at 11:47 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>> 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 <ge...@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 <ka...@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.petracek@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 <ka...@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
>> >> > >
>> >> >
>> >>
>>
Re: CODI: Exclude windowId from certain pages
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
I think I've seen this discussed in this forum within the last few months
(I might be wrong though).
Anyway, I remember a similar topic and a solution, but it wasn't a CODI
solution; this may or may not be related/solution.
Quote from http://stackoverflow.com/a/5475564/933054
*Until what point in time does JSF save the state of UI components on the
server side and when exactly is the UI component's state information
removed from the server memory?*
Those two questions seem to boil down to the same. Anyway, this is
implementation specific and also dependent on whether the state is saved on
server or client. A bit decent implementation will remove it when it has
been expired or when the queue is full. Mojarra for example has a default
limit of 15 views when state saving is set to session. This is
configureable with the following context param in web.xml:
<context-param>
<param-name>com.sun.faces.numberOfViewsInSession</param-name>
<param-value>15</param-value></context-param>
On Thu, Nov 29, 2012 at 11:47 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> 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 <ge...@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 <ka...@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.petracek@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 <ka...@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
> >> > >
> >> >
> >>
>
Re: CODI: Exclude windowId from certain pages
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2012/11/30 Mark Struberg <st...@yahoo.de>:
>
>
> Well, then the problem is not the number of windows but the number of sessions ;)
>
Ok, good to know that.
> In pure tomcat you can either restrict that or 'offload' them via a configuration. There are SessionManagers which keep n Sessions in memory and if this number gets exceeded the LRU ones will get persisted to the file system. 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.
<filter>
<filter-name>OpenWebBeansFailover</filter-name>
<filter-class>org.apache.webbeans.web.failover.FailOverFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>OpenWebBeansFailover</filter-name>
<servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
This works just perfect, but does Weld requires something similar? Sorry, if
this question is trivial, obvious or off the topic.
regards,
Leonardo Uribe
> LieGrue,
> strub
>
>
>
>
>
>>________________________________
>> From: Andreas Kaiser <ka...@gmail.com>
>>To: MyFaces Discussion <us...@myfaces.apache.org>
>>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 to
>>my server ( clean login and logout )
>>
>>BTW. the number of ids is not 500*64 its NumberOfThreadsInJMeter *
>>LoopCount
>>
>>in my case 500 * 200 = 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 <lu...@gmail.com> 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" <st...@yahoo.de> 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 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 <lu...@gmail.com>
>>> > > To: MyFaces Discussion <us...@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 <ge...@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 <ka...@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.petracek@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 <ka...@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
>>> > >>> > >
>>> > >>> >
>>> > >>>
>>> > >
>>> >
>>>
>>
>>
>>
Re: CODI: Exclude windowId from certain pages
Posted by Mark Struberg <st...@yahoo.de>.
Well, then the problem is not the number of windows but the number of sessions ;)
In pure tomcat you can either restrict that or 'offload' them via a configuration. There are SessionManagers which keep n Sessions in memory and if this number gets exceeded the LRU ones will get persisted to the file system. 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 ;)
LieGrue,
strub
>________________________________
> From: Andreas Kaiser <ka...@gmail.com>
>To: MyFaces Discussion <us...@myfaces.apache.org>
>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 to
>my server ( clean login and logout )
>
>BTW. the number of ids is not 500*64 its NumberOfThreadsInJMeter *
>LoopCount
>
>in my case 500 * 200 = 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 <lu...@gmail.com> 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" <st...@yahoo.de> 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 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 <lu...@gmail.com>
>> > > To: MyFaces Discussion <us...@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 <ge...@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 <ka...@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.petracek@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 <ka...@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
>> > >>> > >
>> > >>> >
>> > >>>
>> > >
>> >
>>
>
>
>
Re: CODI: Exclude windowId from certain pages
Posted by Andreas Kaiser <ka...@gmail.com>.
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 to
my server ( clean login and logout )
BTW. the number of ids is not 500*64 its NumberOfThreadsInJMeter *
LoopCount
in my case 500 * 200 = 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 <lu...@gmail.com> 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" <st...@yahoo.de> 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 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 <lu...@gmail.com>
> > > To: MyFaces Discussion <us...@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 <ge...@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 <ka...@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.petracek@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 <ka...@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
> > >>> > >
> > >>> >
> > >>>
> > >
> >
>
Re: CODI: Exclude windowId from certain pages
Posted by Leonardo Uribe <lu...@gmail.com>.
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" <st...@yahoo.de> 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 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 <lu...@gmail.com>
> > To: MyFaces Discussion <us...@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 <ge...@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 <ka...@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.petracek@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 <ka...@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
> >>> > >
> >>> >
> >>>
> >
>
Re: CODI: Exclude windowId from certain pages
Posted by Gerhard Petracek <ge...@gmail.com>.
i agree with mark.
in one of our first benchmarks we used gf (v3.1.1 -> i can't confirm it for
v.3.2.x), as7 and tomcat. back then gf always had the worst results and
sometimes it just broke down completely. however, afair we heard about codi
based projects which do load-tests with a way higher load.
-> imo you would see the same issue with the std. session scope (just a bit
later).
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/30 Mark Struberg <st...@yahoo.de>
> 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 <lu...@gmail.com>
> > To: MyFaces Discussion <us...@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 <ge...@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 <ka...@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.petracek@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 <ka...@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
> >>> > >
> >>> >
> >>>
> >
>
Re: CODI: Exclude windowId from certain pages
Posted by Mark Struberg <st...@yahoo.de>.
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 <lu...@gmail.com>
> To: MyFaces Discussion <us...@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 <ge...@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 <ka...@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.petracek@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 <ka...@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
>>> > >
>>> >
>>>
>
Re: CODI: Exclude windowId from certain pages
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <ge...@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 <ka...@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.petracek@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 <ka...@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
>> > >
>> >
>>
Re: CODI: Exclude windowId from certain pages
Posted by Gerhard Petracek <ge...@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 <ka...@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.petracek@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 <ka...@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
> > >
> >
>
Re: CODI: Exclude windowId from certain pages
Posted by Andreas Kaiser <ka...@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.petracek@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 <ka...@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
> >
>
Re: CODI: Exclude windowId from certain pages
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <ka...@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
>