Well, if JBoss doesn't deserialize session immediately after replication (which i have no idea if it does) the back button will not work. However if you are using sticky sessions (which you definitely should) then this will only be issue when user click back button after a node went down.
-Matej On Thu, Oct 22, 2009 at 10:27 PM, Jan Grathwohl <jan.grathw...@googlemail.com> wrote: > Dear all, > > would you be so kind and share your experience about whether it is > reasonable to use Wicket for app development in the following situation: > > We are planning to develop an application that will be deployed in our > customer's portlet environment (JBoss Portal). There will be two clustered > JBoss instances with JBoss's own session replication mechanism enabled. The > main reason for the clustering is to have failover that should be > transparent for logged in users, and this has to work really reliably. I > don't know what the exact configuration of the load balancer and the JBoss > servers will be, and how much influence we will have on it. > > Is it safe to use wicket in such a situation, or should we rather go for a > more stateless framework? > > I did some tests to run a very simple Wicket app in two clustered JBoss > instances, and after I shut down the instance with the active session, the > session continues to be available on the other cluster node, and the links > in the pages still work. So far, so good. But when I hit the browser's back > button, I receive a Page Expired Error. This probably means that the content > of the page store is not correctly replicated to the other cluster node? > > Is this a known limitation, or caused by some wrong configuration? > > Thanks for any feedback on these topics, please let me know what your > experiences and opinions are. > > Kind regards, > > Jan > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
