myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: CODI: Exclude windowId from certain pages
Date Fri, 30 Nov 2012 06:34:59 GMT
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. <smithh032772@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 <lu4242@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 <gerhard.petracek@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.andreas@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 <kaiser.andreas@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
>> >> > >
>> >> >
>> >>
>>

Mime
View raw message