Hi all, I am currently evaluating a Wicket fail-over solution (two equal nodes with a floating IP, probably using Linux Heartbeat) with Terracotta. Of course, it would be desirable to switch between nodes without any impact on a user's session. In order to provide this, the cluster must be able to handle non-sticky sessions. Session clustering works like a breeze with Wicket and Terracotta
I already spotted a problem with buffered redirects, that could be avoided with a different rendering strategy (IRequestCycleSettings.REDIRECT_TO_RENDER). However, this problem would only occur if a node goes down just when the client is redirecting - not very likely and probably acceptable as switching over might take a few seconds anyway. Now my question: What other problems could appear when I only use session clustering for fail-over purposes? Can I stay with the default rendering strategy (IRequestCycleSettings.REDIRECT_TO_BUFFER) without clustering the buffer if I accept missing feedback messages in the above scenario? Any further comments on my setup will be appreciated as well! (If answers are woth it, I'll create a wiki page out of this thread) Best Regards, Stefan ----- ------- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Wicket-fail-over-with-Terracotta---sticky-or-non-sticky-sessions--tp16467830p16467830.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
