incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Trinidad session handling & replication, configuration issues
Date Wed, 23 Aug 2006 15:52:31 GMT
Frank,

If you're using Trinidad with a recent-ish (1.1 line) Facelets, you might
try looking at adding the following experimental parameter to web.xml:

  <context-param>
    <param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
    <param-value>true</param-value>
  </context-param>

I'm not really sure what explains the 300K vs. 30K difference,
as MyFaces and Trinidad are basically saving the same raw
information.  It could be a difference in the number of views
saved (I think Trinidad defaults to 10, don't know what MyFaces
is doing), or behavior where MyFaces is pre-serializing (by default),
while Trinidad isn't, etc.  (If it were an issue of pre-serializing
vs. not, then it wouldn't matter for actual replication!)

BTW, if you're interested in the *why* of session state being
so darn large, I wrote a blog entry that touched on this:

http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html

... and some about the BUILD_BEFORE_RESTORE option:

http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html
http://sfjsf.blogspot.com/2006/03/fixing-jsf-state-saving-progress.html
http://sfjsf.blogspot.com/2006/03/fixing-jsf-state-saving-save-vs.html

I need to get back to blogging...

-- Adam


On 8/23/06, Frank Felix Debatin <ffd@gmx.net> wrote:
>
> We're in process of trying different setups to determine a
> good production environment that shall include session
> REPLICATION. We use load tests (based on JMeter) to check
> the setup.
>
> We currenty use Trinidad & Facelets. Faces implementations
> we tried are RI 1.1, RI 1.2, MyFaces 1.1.x. For Trinidad
> we're using a version from before the renaming activities
> started.
>
> Now we got lost in the jungle of faces implementations and
> session/view handling. I also admit that although we got a
> very large app running, we don't understand the JSF/Trinidad
> session/view handling completely (and we don't want too
> unless we must).
>
> Here is my basic question:
>  ***  What is the best combination of faces implementation
> and session state configuration for a production environment
> with session replication? We're looking for a "reasonable"
> size of the serialized session.
>
> All hints/observations/recommendations/explanations are
> welcome!!!
>
> Some notes we made see below.
>
> Hoping for feedback
> Frank Felix
>
>
>
> 1) VALID COMBINATIONS
>
> For Trinidad, we use the default settings (token
> mechanism?).
>
> We found:
> * JSF RI 1.1, 1.2: work only with state saving set to client
>
>
> * MyFaces: there was Adam's recent comment
> >>>
> When you use Trinidad with MyFaces, because of how things
> are set up, the only options are MyFaces server-side and
> Trinidad client-side.  Trinidad doesn't provide a
> server-side version, and overrides the client-side version
> entirely (RI or MyFaces).
> <<<
> We (without any reasoning) always had JSF state-setting set
> to "client" in development, with MyFaces 1.1.0. Worked fine.
>
>
> Now, we have MyFaces 1.1.3 with "server", and have several
> problems (date popup windows don't work, back-button issues,
> and so on). Probably due to 1.1.3 problems, I read that this
> release is not considered to be a "good one".
>
> 2) SESSION SERIALIZATION IN REPLICATION
>
> We are concerned about the size of the session after
> serialization. When state saving is set to "client",
> Trinidad (rather old version) writes a token cache with
> ~300K to the session. With server side state saving, Myfaces
> 1.1.0 writes nothing, Myfaces 1.1.3 a serialized view
> collection (~30K).
>
> Now 300K is too much, and still 30K sounds a lot to us.
> Session failover is a very exceptional case, and it wouldn't
> be a serious issue if - in the failover case - the user
> experience "falls below the usual level". I can't imagine
> that there are 30K-300K of really critical data.
>
>
>
>
>
>
>

Mime
View raw message