incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Felix Debatin" <...@gmx.net>
Subject Trinidad session handling & replication, configuration issues
Date Wed, 23 Aug 2006 10:12:22 GMT

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