A sticky load balancer doesn't solve all the problems, for eg: if the app has to be bounced or the machine has to be rebooted etc, in these cases if the state management is at the server side, then the user's page will be just refreshed as the app doesn't have the component tree, this would be a bad user experience. I am looking for any other way to get best of the both worlds(low page size and a true load balanced app.)
-----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 11:16 AM To: MyFaces Discussion Subject: Re: Jsf_tree_64 Gattu, Praveen wrote: > Hi Folks - We are using the myfaces(1.1.5 snapshot). I got couple of > questions regarding the state save. So far we were using the server > side save state to reduce the page size of our pages, but noticed that > with this approach, our app cannot work behind a load balancer. We are > using Tomcat as webserver, and we donot intend to use tomcat > clustering. In order to avoid this we switched to client side save > state. Although this solved the load balancing issue, we saw the page > sizes increase by 10-15x. A page with server side save state with a > size of 18kb, now measures ~300kbyes with client side save state. > > I noticed that the framework is using "jsf_tree_64" hidden field for > all the command links, to store some form of data. What is this field > used for in the framework? Saving the current component tree. It needs to be stored somewhere, and if you don't want it in the http session ("server-side state") then it has to be stored in the form ("client-side state"). Is there a way to avoid this hidden field, without > using the server side save state? Nope. Are there any other approaches I > should be looking to solve both load balancing and low page size? Perhaps a "sticky load balancer", ie one that is http-session-aware and therefore directs all requests for a specific session to a single tomcat instance? I can't see any other alternatives, if you're opposed to clustering; the tomcat instance that handles the submit must have the component tree data available, and the only options are (a) in the http session, or (b) embedded in the posted data. Regards, Simon
