On Mon, Feb 25, 2008, Alex Rousskov wrote: > On Sat, 2008-02-23 at 03:34 -0700, Adrian Chadd wrote: > > Can someone please explain the logic behind this? > > I think I understand, but I'd like to know what people are trying > > to achieve. > > The overall goal is robustness: make production Squid installations > crash less often. In this particular case, we are trying to kill the > transaction or job that hit an internal error (a.k.a., assertion) rather > than killing the whole Squid. If our attempts to isolate the failure > fail, Squid aborts as before. > > The assert_burst_max configuration knob controls whether Squid tries to > be robust and how hard it tries to do that. The logic is experimental > and is likely to change once we get more experience with this feature.
Although I applaud the effort, I'm not quite sure this is at all a good idea, even if it seems so. All the current assert()'s are invariant conditions which the following code then assumes holds true. They haven't been used as debugging statements for as long as I've been involved in the codebase. Treating them as a point to unwind the transaction seems unwise. If something unwise happens then Squid should die, rather than starting to do possibly damaging things to the content going through it. I'd hate to see a credit card transaction being partially aborted because Squid hit some internal error. If we actually wanted to make production Squid installations crash less often, then we should make a point of requiring all new code to be written with no assert()'ions outside of debugging, check return values and percolate errors/ exceptions back to the original caller. We should then make the base routines return something sensible (my eye being on things such as malloc/free); and slowly migrate all code over to doing something sensible in those conditions. If you want this sort of thing to be a goal then it should be a project goal, not just hacked into the side. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
