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