[
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