I agree and disagree with this. Shared/clustered session support adds a level of complexity to the web solution, which I consider to be onerous to set up. Plus you have delay in session sync, and restrictions on what you can place in session support among other things. It depends on what you're balancing. To say it's a solution in all cases is overly simplistic... But I'm glad it works for you.
I'd argue since commercial load balancers in this space all support cookie based affinity at the browser level, managed by the load balancer... the market has clearly shown a demand for persistent session affinity in the load balancer regardless of backend application. (Just a few I've researched are CoyotePoint, KEMP, A10, F5, RadWare) Joe > -----Original Message----- > From: Jacob Anderson [mailto:[email protected]] > Sent: Friday, December 30, 2011 11:32 AM > To: [email protected] > Subject: RE: [Pound Mailing List] Pound 2.7 > > Sorry to chime in here on this topic, but this really isn’t a pound > function. If you are losing your session data because pound bounces > your client to another BE, then you need a shared session state machine > for your back ends. > > We do this in ASP.NET with the session state server and it works > incredibly well. Our sessions are all high dollar value, so if we lost > one, our customers would really get irritated with us. To date, we’ve > not lost a single session as a result of bouncing a back end. > > If your technology stack doesn’t support a shared session state > manager, … well it might be time to write one or consider a new stack. > Pound should never do anything application related. > > I am +1/2 (half) on the active reload of a config when the config file > changes. Only half because doing this would likely be a version 3 > feature, not a revision feature like 2.7…. > > -- Jake > > > From: Paolo Nesti Poggi [mailto:[email protected]] > Sent: Friday, December 30, 2011 7:57 AM > To: [email protected] > Subject: Re: [Pound Mailing List] Pound 2.7 > > Hi, I'm not (yet) a user hence at risk to say something not well > thought out, however: > When/if this (no downtime config reload) is available, then the ability > to close for new connections/sessions to a specific back-end server, > while letting current active sessions extinguish, possibly with a > configured time-out. > In this way it would be possible to disconnect a back-end server for > maintenance without loosing active sessions. > > /Paolo Nesti Poggi > eaktion.com > > Den 30-12-2011 16:05, Erik Hensema / HostingXS skrev: > THE killer feature: reloading the config without downtime. Currently > it's impossible to reload the config without losing all sessions. > > On vrijdag 30 december 2011 15:44:06 Robert Segall wrote: > > Hallo everybody > > > > New year, new version: we declare open the wish-list for 2.7 > features. > > Please reply to this with your list of enhancements/patches/wishes. > > > > Please feel also free to offer comments (supportive or not, as the > case > > may be) on items that others may post. The more support for a > feature, > > the better its chances of making it into 2.7. > > > > Please do NOT post patches in reply - a short description is quite > > enough. You can mail me directly if you want to offer patches. > > -- > Met vriendelijke groet, > > > Erik Hensema > -- > HostingXS B.V. > eXcellent Service > > Support: [email protected] > Algemeen: [email protected] > Administratie: [email protected] > > Telefoon: 024 - 324 91 77 > Fax: 024 - 324 91 76 > > Post adres: > Postbus 5 > 6500 AA te Nijmegen > > Website: http://www.hostingxs.nl > Twitter: http://twitter.com/HostingXS > Facebook: http://www.facebook.com/hostingxs > > > -- > ------------------------ > Eaktion.com > www.eaktion.com > Tlf. 77410237 > ------------------------ > -- To unsubscribe send an email with subject unsubscribe to > [email protected]. Please contact [email protected] for questions.
