[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [starter-dev] Return of the Dreaded View Expiration!
|
- From: Reza Rahman <reza_rahman@xxxxxxxx>
- Date: Fri, 14 Mar 2025 12:36:04 -0400
- Delivered-to: starter-dev@xxxxxxxxxxx
- List-archive: <https://dev.eclipse.org/mailman/private/starter-dev/>
- List-help: <mailto:starter-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://dev.eclipse.org/mailman/listinfo/starter-dev>, <mailto:starter-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://dev.eclipse.org/mailman/options/starter-dev>, <mailto:starter-dev-request@eclipse.org?subject=unsubscribe>
- Ui-outboundreport: notjunk:1;M01:P0:t3PN8QCwB28=;UMSC+wGAUx7PQ3VwHxjaoFhUY9W TLqvtdE6bQZvTb2O4J7TTz/ePGD+OfQVfj5mSvfvXVch0/x7pumCoOpMAVnDBt0f2OgtocVDM fBGx+w05GFI6vSBFlU+ejPEC66AmGAir33Nlqdp+bsZYxwZfOklrOFdqd8a0QpcOSqc8Z5bTA Pef1EaQQgCJ3cytWfAETnBt0X78aVbIloYpRwUf9ZHy+HMO0Zve8LVEo8Hglk7nU7s5k33pFJ 064Gyt0O2EAIlVNz6IiZVAqVVEEh46d8uJK+POhbBQvpbWbdzR9NekqRvXvGnDVSlGbQsssIf 2L12PVRvsV3oXqohTVyf9BaGrT2YrE+8I0NbLV1Ve+Q+kJZala2V8FvUQ01tXgtj5b7MOevkq u7wvY6hFqBkYVzbMdhmPkQf35qEBZjWsp6gJmPd/Tu3f8VbLNLTcA0lT183y4dKTHJHYd5L+2 8JejDXJvDr/8GDGKdpBYRyg+HvG+20gMM+4i0ixBMWEhIc1af/jY5cj4RmEa49reSHbE+lKnk x+T8GupnRzOXAlXBqB5duCfm2n5bEd2vGx777yJur4WEuAep11A6DeC7D9fp6ScHRfSwXYSyk /UW4V0+fTzC7zUJkIezQ47wcWlhCtgsDiMckH280s8lgi8MIPeYa317xAGDtSteUPqILvdExa 7t8RP3DmjoOJGFc8I9iLQXMtJN2ZwjWA9WcA4SmqX6D13p08beoP5ofNjpw6RDYAShHKGBx8O Wb5sl2cJDmfzm32XHKBNtNEd8mCm/hhsignG3ybIKA6Ispzukf/W1DbhKXLzDnNky3fE6hxvf H4gWXS0fmxmfAm4HHLQYhoD9qfj4OoL0rkJwjFdVUpR7z+tGshlGEIByJqgR+W/woe4X+/PvW Td2CEaQMgTOZ4S/YWTiAW3aRMw2h7yD3MZo77UwLuAaXPAZuLFztndw3ho4uE7qKRvMKuXK/7 kwhNkMcCfHRfPaUXlWr/Oy1BPkhQwgCLo/mfNFG2Kb1ny6WTFXK1h1vKxhlS//wfsnTmLDgYn 4hyMKmwd8xqo/CxhBYZ9DBjqiFABsx+92eyD7Y4xzy70gaPTTEKTjimEcWDISUT+Tw5pZcVkA iDWUMaQjZ/ZweFs2Ie8Y85FhPjEgdtCehpziRx9AW7bQ731vgVEWJ2fKwg1cidX7FdUTM339o U+awZiGteVukBVDrImvPyNFkQf2d19e5t47fpiGbYa/tdXubsZ8ACysm96zEdJPbtgvN47l1w /8Yph9oxrTWvAY2Wn02j8TX1AaWL0f7UGTzcNQckPvqmO80ZZW+6h/Ct2e2wXIILwRRnSuupn 2G1290jcFP+tiUFt15ElweRtm5nMyrgbENiuaYLTLJgb/bTRV176aoDUJCeKY7V8EKiu2wXtS KbVgAvKXrtpZaaXddPHFakA02yv5bX/Oin2AZamwLsKEiQUPxAxArU2D1c07n0j0KV1tbFmOC xgkLDi8rbpI0BQbigvx1m2LGVBdQyAWzFh9i0RQO3yZvgQjyHWsKp5WVp6j7amPmpcziTsw==
- User-agent: Mozilla Thunderbird
Sounds good.
Jeyvison, can we have a new release of just the UI please? I've
tested the change and it appears fine. Bear in mind, I just merged
a long-standing PR from Ondro into the Archetype part that isn't
ready for prime time yet, so please don't do a corresponding
release of the Archetype yet? Just the UI please?
I appreciate it!
On 3/14/2025 12:26 PM, Bauke Scholtz
wrote:
On this specific public facing app, I suggest keeping
client state saving. This will further reduce
ViewExpiredException risks as well as headache risks and hence
in long term better for well being on both sides.
Cheers, B
I found out that session affinity was indeed
turned off and I have now turned it on.
Before deploying this change, is it worth it
to observe if this simply solves the problem? Or should I
switch to client state saving anyway?
WDYT?
try to ensure sticky
sessions for good measure
Cheers, B
OK, great. Let me test it and get
it deployed. I'll monitor for any more issues and also
try to ensure sticky sessions for good measure. Thanks!
On 3/14/2025 11:53 AM, Bauke
Scholtz wrote:
Cheers, B
Do you mind kindly making a PR
with the approach you think is best overall? I'll
test it out and monitor that it works. I appreciate
it!
On 3/14/2025 11:45 AM, Bauke
Scholtz wrote:
Yeah. The issue
boils down to that the view scoped bean referenced
in the p:selectOneRadio is created for the first
time when the response is already committed. And
view scoped beans need to be saved in the session.
But when the response is already committed the
cookie associated with the session cannot be set.
Another solution
is to add a f:viewAction referencing some bean
init method and use that instead of postconstruct.
This is guaranteed invoked before render response.
Yet another
solution is to create a servlet filter which does
an explicit request.getSession() call.
You got it.
Cheers, B
To some extent, the
symptoms at least appear simple. We are now
getting copious amounts of views expired
(example stack trace attached). I had seen this
in prior releases with JBoss EAP 7.4 (and the
corresponding WildFly version). What I did is to
set STATE_SAVING_METHOD=client. It worked well
and saw no more views expiring in the logs.
Then we upgraded to JBoss
EAP 8 and the corresponding WildFly versions.
Now with STATE_SAVING_METHOD=client, I get this
strange session state saving issue (example
stack trace also attached). So we are stuck with
views expiring again.
Let me know if I can share
anything else. Let me see if there is anything I
can do to ensure sticky sessions. Because this
is deployed to an Azure PaaS, I have a very
limited amount of control.
On 3/14/2025 10:58 AM,
Bauke Scholtz wrote:
Hi,
I had to
remove STATE_SAVING_METHOD=client because I
could not get it to work
Would be
helpful if you elaborate this in detail. It
might be a clue. One of pre-requirements for
that in a cluster environment is that the jsf/ClientSideSecretKey
env param is set (usually in web.xml). This
has been renamed to
faces/ClientSideSecretKey. So if the cluster
doesn't use sticky sessions then
ViewExpiredException will occur.
Cheers, B
Hey Reza,
Can you provide some
more details (perhaps point me to logs or
explain any scenarios)?
We're still partners
with PrimeTek and I still work with Bauke
Scholtz (cc'd), so we can figure it out.
Hi Kito/others,
I have been monitoring the release for
stability and unfortunately we
have a problem that needs to be solved. I
had to remove
STATE_SAVING_METHOD=client because I could
not get it to work with the
latest PrimeFaces/Jakarta EE 10/JBoss EAP
8. Now we have the infamous
JSF problem of views expiring left and
right again of course. I will
keep trying this weekend, but can you
possibly help me look at this and
solve it? You still have some contacts
with the PrimeFaces folks, right?
Could they help? This appears to be mainly
a PrimeFaces problem.
Thanks,
Reza