Re: Robustness project adjustments

On Thu, 2008-03-13 at 21:15 +0200, Tsantilas Christos wrote:
>
> > 1. The assert() code will not throw exceptions by default. It will
> > continue to call abort() as before. To enable the robustness feature, a
> > squid.conf option will need to be set. (In the future, that option may
> > contain a date value so that it automatically disables itself if the
> > administrator forgot to do that after fixing the problem.)
>
> As I can understand the assert() by default will abort squid as before.

Correct.

> In async-calls branch there is the "assert_burst_max" configuration
> parameter which has a default value of "100". If set to "0" then the
> assert() call aborts immediately squid.
> Is it enough to set the default value of assert_burst_max to "0" or we
> need an extra configuration parameter to enable/disable the feature?

It is enough to change the default, I think.

> > 2. Assert() calls that are testing local, transaction-specific
> > conditions will be manually converted to Must() calls. Must() always
> > throws an exception. It is already used by the ICAP code. Must() name
> > comes from IETF RFC MUST/SHOULD/MAY terminology. Suggestions for a
> > better name are welcome. New code should use Must() whenever possible.
>
> Assert() with capital "A" it is not a different function than assert(), OK?

Same function; I should not have capitalized it, sorry.

> If I am not wrong we should discover the "safe" cases and replace assert
> calls with Must() calls. Am I right?

Correct.

> Must() call will have its current form (justs throws an exception) or
> will get some of the features of assert() call (eg. assert_max_burst
> feature)

Must() call retains its current form. Must() exceptions will be either
handled by the current job or kill Squid. In the second case, it would
be nice to print something intelligent before abort()ing, I guess.

> I think Must is a good name, maybe in the future a "Should()" call
> implemented which in addition allow squid to respond to the http client
> with messages like the "500 Internal server error " etc :-)

Not exactly. Should() is for proceeding further with a debugging message
printed to cache.log if the condition fails. Unlike Must(), Should()
returns a boolean value so that the caller can detect and handle the
minor inconsistency. Should() is quite handy, but unrelated to
robustness issues.

May() is a no-op, just like in RFCs.
 
> > 3. Transactions that can handle exceptions with a proper cleanup will
> > continue to handle them without aborting Squid. Other transactions will
> > abort Squid if an exception is thrown. This design remains unchanged
> > compared to the original version: we are changing when exceptions can be
> > thrown, not how they are handled.
>
> OK.
>
> >
> > 4. We will continue to work on the transaction cleanup code.

HTH,

Alex.
Received on Thu Mar 13 2008 - 17:12:36 MDT