Alex Rousskov wrote:
On 02/23/2009 05:28 PM, Amos Jeffries wrote:
Sigh, another design flaw in the current config handling.
Exactly how are they in use, and which ones?
NP: reconfigure and shutdown both call the free-up after all client
connections are supposed to be dead. And all non-memory management
components are already shutdown.
'reconfigure' global is available for selective preservation during
reconfigure.
I do not know whether the objects in scope of the patch are incorrectly
maintained during the reconfigure, but it is possible that the patch
would be correct if object maintenance is fixed.
However, the whole idea that you should shutdown everything, delete
virtually everything, and then create and configure "from scratch" is
obsolete, IMO. Making reconfigure nearly identical to restart is
simpler, but it is just not good enough for busy proxies.
If the store can be used by more than one squid processes there is a
very simple solution: Shutdown the squid processes with old
configuration (waiting all old sessions ended) and start new squid
processes with the new configuration. I am wandering how difficult is to
implement shared stores in squid...
At this point, I do not know whether we should invest cycles in fixing
leaks under the "from scratch" model or focus on migrating to "live"
reconfiguration. Perhaps the answer is the "reconfigure" global you
mentioned. This is something that should be discussed.
Thank you,
Alex.
