Trinidad session handling & replication, configuration issues

[Frank Felix Debatin <ff...@gmx.net>]

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. 

Re: Trinidad session handling & replication, configuration issues

[Adam Winer <aw...@gmail.com>]

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 <ff...@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.
>
>
>
>
>
>
>