A few thoughts:
- Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support
the browser back button!
- try to reduce the number of components (e.g. conditionally controls
can be excluded at compile time via c:if or via dynamic includes instead
of visibleOnUserRole or rendered
- Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support
the browser back button!
And once a user opens another browser tab all will crash :(
The missing windowId support is really a pitty in the JSF spec, and we
currently think hard about how to solve this (at least in
If we go with client side state saving what kind of performance hit can we
expect?
Going this route does this make assumptions on the type of machine a user has?
The browser that they are using?
From the myFaces wiki, I see that if we go with client side we have the issue
of serialization.
Hello David,
How large are your pages? Do you have several tabs each with nested tabs and
lots of fields? Which component suite(s) are you using?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
hi thomas,
since we might move it to codi after v1.0.2, there won't be a deployment
(for now).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/17 Thomas Andraschko
Hi Gerhard,
thanks, it works!
2011/10/17 Gerhard Petracek gerhard.petra...@gmail.com
hi thomas,
i see. in this case you need the cditest-owb module of owb (it's in the
same
example).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Still (I know it is not an option) but if you need to reduce session
space JSF 2 is the way to go, the delta state saving can free a load of ram.
Werner
Am 10/17/11 10:58 PM, schrieb Scott O'Bryan:
Wow.. Looks like you've done a lot, but I personally think 5K is
unrealistic. Your right.
Scott,
With your comment below but do you feel is a more realistic targeted
size for session size with JSF?
All,
Based on some of the comments, is this not an issue for others that make
use of this Technology or did we basically implement it incorrectly -
from the way the .jsp are created to
David,
Usually memory is the problem - but sometimes there are also CPU problems -
you can run WebSphere for example on the Mainframe. Compared to a Linux Box
CPU time can be expensive there.
Are you running on a 64 bit Architecture? Memory is not that expensive these
days ;-)
What is you total
+1 mem is barely a problem these days.
Actually we are serving 60.000++ users per day without any mem problems (w 100
views/session ServerSide-StateSaving).
We need some low GB mem on our 48GB RAM server...
Even if you have 1MB of session mem per user then you can serve tons of users.
We are running under Red Hat with WebSphere 7 64-Bit.
Currently heap is set to 8 G. The issue seems to be around the ability of the
server to replicate the data across all the servers. We get complaints from
the users of lost information during a server hop
Thanks
-David Boyd
(Sent via
We tend to run higher sizes for our users. Currently running at 4M but as high
as 25M.
But it is good to see some real numbers and possible targets/guidelines that we
should be shooting for.
Thanks
-David Boyd
(Sent via BlackBerry)
- Original Message -
From: Mark Struberg
I'm using string tables and to i18n some messages using jsf and I've got
some unexpected behavior
if I have a string table
string1=boldasdf/bold
string2=my cow is brown
if I then go on to a jsf page and do
#{msg.string1}
#{msg.string2}
the result I get is
lt;boldgt;asdflt;/boldgt;
my cow is
Ted,
The strings will only be escaped if the component you're using escapes the
text. If you're just embedding the expression in the page, it's not going to
be escaped, but you can use h:outputText -- this allows you to control
whether or not you want the text escaped.
---
Kito D. Mann | twitter:
14 matches
Mail list logo
