Ok, so this would be a reason that client side state saving takes so much longer for our load tester - GC running and running.
Right - cause it doesn't work with server side state saving either as soon as restoreState/saveState is enabled server-side on every request. Then it might also have been a JDK version or OS problem, though. Does Oracle have any concrete data on this you are allowed to share? Maybe not into the detail, but some overview would be great ;) regards, Martin On 11/16/05, Adam Winer <[EMAIL PROTECTED]> wrote: > You probably do need to restore all of the ancestors of a component, > since things like NamingContainers had better be present. > > Also, not restoring the entire tree introduces extra problems - > especially if you want to respond to an AJAX request on one > component by refreshing others (a common > scenario over in ADF Faces). > > Martin, memory allocation can be a significant problem, not > in terms of not having enough physical memory (that is, > not in terms of seeing OutOfMemoryErrors) but in terms of > pounding brutally on GC especially if you blow out the Eden > heap. This'd show up as CPU, but could be a consequence > of excessive short-term memory allocation. > > -- Adam > > > On 11/16/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > Yes - this is what would be the best thing to do. > > > > Jacob is calling this something like context-sensitive processing or so. > > > > regards, > > > > Martin > > > > On 11/16/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > One idea I had was that it would be nice if you could jump right to a > > > specific component without restoring the whole tree. In other words > > > you have async post for component with id of "foo" and you can grab > > > that directly out of a session map and perform the full lifecylce (but > > > just on that component.) > > > > > > If the component had children you would process them as well. Just > > > some random thoughts. I'd be interested in hearing other ideas. > > > (I'll do some research on the blogs and forums and see what others > > > have suggested.) > > > > > > sean > > > > > > On 11/16/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > Martin, > > > > > > > > If you look at any postback, the areas that chew up time are: > > > > > > > > 1. Recreating the component tree > > > > 2. Going through the full lifecycle > > > > 3. Saving the component tree > > > > 4. Rendering the response > > > > > > > > If you want a hyper-efficient async, granular JSF response, you > > > > have to tackle each of these, both in terms of raw CPU and > > > > memory allocation (the latter more important when you look > > > > at multi-user scalability). > > > > > > > > Each of these has its own trickiness, and is harder than it > > > > seems at first. :) I really have to start blogging; each of > > > > these is like a separate article... > > > > > > > > So, yes, optimizing the lifecycle is a good start, but it's not > > > > a complete solution. > > > > > > > > -- Adam > > > > > > > > > > > > > > > > On 11/16/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > > Sounds promising to me! > > > > > > > > > > Even though from the perfomance tests that have been posted to the > > > > > mailing list a while ago, it doesn't look like going through the > > > > > lifecycle is the big problem - but rather restoring/saving the state > > > > > if you use client-side state saving. > > > > > > > > > > Adam, can you confirm that from your experience with ADF Faces? > > > > > > > > > > regards, > > > > > > > > > > Martin > > > > > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > Thanks. That confirms what I suspected (as far as being able to > > > > > > have > > > > > > a custom lifecycle using an init param.) > > > > > > > > > > > > So the suggestion would be in MyFaces to create a new custom > > > > > > lifecycle > > > > > > that included the default lifecycle and other optional steps. With > > > > > > the right URL or request parameter you would use the nonstandard > > > > > > phases (or jump around in a non-standard way). Otherwise you would > > > > > > follow the standard steps only. By default (without the special > > > > > > servlet context init parameter) you would get the default lifecycle. > > > > > > Would this work? > > > > > > > > > > > > sean > > > > > > > > > > > > On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > > You can configure FacesServlet to have a custom lifecycle using > > > > > > > a servlet context init parameter. But you can't, say, have two > > > > > > > FacesServlets each running a different lifecycle - one standard, > > > > > > > one trimmed for AJAX-ing. That's what JSF 1.2 adds, because > > > > > > > you can configure the lifecycle ID as a servlet config > > > > > > > parameter, not just a context init parameter. > > > > > > > > > > > > > > -- Adam > > > > > > > > > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > > > I think Craig was referring to the *current* ability to > > > > > > > > configure a > > > > > > > > custom lifecycle. From the javadocs it looks like this is > > > > > > > > supported. > > > > > > > > Can you clarify this some? > > > > > > > > > > > > > > > > sean > > > > > > > > > > > > > > > > On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > For the type (a) components (where you need the component > > > > > > > > > > tree and > > > > > > > > > > model), Craig offered an interesting solution. He was > > > > > > > > > > toying with the > > > > > > > > > > idea of a custom lifecylce. I hadn't even realized this > > > > > > > > > > was possible > > > > > > > > > > but it sounds interesting. > > > > > > > > > > > > > > > > > > > > I posted something on struts-dev asking him for more > > > > > > > > > > details. Not > > > > > > > > > > sure if it belongs in MyFaces or Shale but it could be > > > > > > > > > > worthwhile. > > > > > > > > > > Perhaps we could modify FacesServlet so that the default > > > > > > > > > > lifecycle > > > > > > > > > > still applies but that you can also configure it with a > > > > > > > > > > specialized > > > > > > > > > > lifecycle. > > > > > > > > > > > > > > > > > > JSF 1.2 offers support for configuring multiple instances > > > > > > > > > of the FacesServlet with different lifecycles. Jacob's idea, > > > > > > > > > IIRC. (Craig hasn't been especially involved in the JSF > > > > > > > > > EG for quite awhile now.) > > > > > > > > > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > http://www.irian.at > > > > > > > > > > Your JSF powerhouse - > > > > > JSF Consulting, Development and > > > > > Courses in English and German > > > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
