Re: Robustness project adjustments

Hi all,

Alex Rousskov wrote:
> Hello,
>
> This email describes upcoming changes in the Squid3 robustness
> project. The Squid3 robustness project has two related goals:
>
> .......
>
> The current design has been disculeassed at the London meeting, and a few
> adjustments were requested. This email attempts to summarize the
> adjusted design.

I have some questions about the adjustments.

>
> 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.

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?

>
> 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?

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

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)

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 :-)

>
> 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.
>
> Corrections and improvements are welcome.
>
>

Regards,
    Christos
Received on Thu Mar 13 2008 - 13:16:09 MDT