Backend cookies patch is here https://users.k12system.com/mrwizard/pound/pound_26_backend_cookies.patch.bz2 "init script" patch is here https://users.k12system.com/mrwizard/pound/pound_26_initscript.patch.bz2
Joe > -----Original Message----- > From: Joe Gooch [mailto:[email protected]] > Sent: Friday, December 30, 2011 12:21 PM > To: '[email protected]' > Subject: [Pound Mailing List] FR27: Hot Reconfiguration > > I anticipate this topic is going to run long, so I thought it best to > have a separate thread. > > I think there are probably two issues here. > 1) Maintaining Sessions across Pound Restarts > 2) Changing the configuration either without restarting pound, or with > #1. > > > I see various approaches to these two problems. > > For 1), session persistence. > a) Move session persistence out of memory, and push it back on the > remote browser. > > This is usually done by having the load balancer generate a cookie > value that identifies the backend, send that cookie to the browser, and > then when a request comes in, the request itself has the backend it's > associated with. So far every commercial load balancer I've looked at > has had this feature. In this case, rebooting the server, restarting > pound, or for that matter, moving the ip to a new box (in a manual or > automatic manner) with a similar pound config does NOT destroy session > affinity. > > Plus I made a patch for it, so I'm partial to this. :) > > b) Use a scripted solution w/ poundctl > > Before I did soln a, this was my solution... I had a cron capture > poundctl XML output of sessions, and then made a small "init script" > patch to pound, such that pound will run the script once the config has > been read, and the poundctl interface is available, but BEFORE it > starts handling requests. The script I had it run would rip through the > XML structure of the last save state and inject sessions back into the > state table. Crude but effective. > > Patch for this is also available, plus I can contribute my scripts if > useful. > > > > Both of those will work well even if backends are added or deleted... > > 2 - hot config, is much harder. > > I'd be curious to hear from the people who want this, what types of > configuration changes might you need to make "hot"? Add/remove > backends? Change headeradd or headerdeny or certificates? Specifics > would be helpful. I'm really curious as to why some of the other > posters are changing their configurations several times a day. > > As far as implementing it I see a couple approaches. > a) Ignore this entirely, since you can change the config, test, > restart, assuming you have a solution to problem #1 above. > b) Identify common changes necessary to make hot, and make sure the > poundctl interface supports them. > b.1) Need to wrap a UI around poundctl, which might be an external > project or some other thing... Doubtful that we'll be going to the > command line to make such changes on a regular basis. Plus if the > changes are going to persist across restarts, they'd need to be in the > text config anyway... > b.2) Maybe the ability to read the running config and write it OUT to > the pound cfg format. So maintain w/ poundctl but have the ability for > those config changes to persist. > c) Modify the config parser to write to heap variables, and parallel- > load a new config. Wipe the old, replace the running config with the > new. This is very problematic, because it would be VERY easy to leave > dangling pointers around in session state and other persistent > structures. The nature of the data structures and C pointers is likely > why this hasn't been done to date. > > > Personally, I'm in the 1-a 2-A boat. But I could possibly see the need > or benefit for some of the 2-b features above... I'd love to hear more > specifics from the community. > > > Joe > > > > -- > To unsubscribe send an email with subject unsubscribe to > [email protected]. > Please contact [email protected] for questions. -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
