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.
