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
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.
Robustness project adjustments
Hello, This email describes upcoming changes in the Squid3 robustness project. The Squid3 robustness project has two related goals: - Prevent Squid from crashing when a non-critical assumption about transaction state fails. Currently, most such assumptions are expressed using fatal assertions. - Provide clean transaction termination code in the presence of errors. Currently, many transactions are very difficult to terminate cleanly if the termination condition is detected deep inside the calling stack. Christos Tsantilas has implemented the first version of the relevant code, with a few design bugs contributed by me. In the first version, assert() code would optionally threw exceptions instead of aborting Squid. Transactions that could deal with exceptions (e.g., ICAP) would terminate cleanly. Others would abort Squid when the exception is propagated to the transaction boundary. Christos has also worked on making non-ICAP transactions more exception-friendly. The feature was enabled by default and controlled via squid.conf. The current design has been discussed at the London meeting, and a few adjustments were requested. This email attempts to summarize the adjusted design. 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.) 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. 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. 4. We will continue to work on the transaction cleanup code. Corrections and improvements are welcome. Thank you, Alex. P.S. The word transaction should be interpreted as asynchronous job in the above. Most jobs are currently protocol transactions, but the robustness code works at the AsyncJob level. As AsyncJob API propagates to other Squid areas, we may be able to handle, say, isolated cache disk failures in a similar way.
