* Choices.
Overall, there are three options for handling an impossible situation:
1. Quit Squid process. This is what Squid does today in most cases.
When the impossible happens, you get a crash. Very predictable.
No malformed/corrupted/misleading HTTP messages (some are truncated).
No memory leaks.
2. Quit the current processing sequence but keep Squid process running,
assuming that [most] other processing sequences are not affected.
[If you are familiar with programming, this is done by throwing
exceptions instead of asserting and catching those exceptions at
"processing sequence" boundaries].
3. Keep executing the current processing sequence, assuming that the
assertion was wrong or unimportant. This is what you might be
suggesting above. When the impossible happens, you may get a crash,
memory leaks, malformed/corrupted/misleading HTTP messages, or normal
behavior, depending on the assertion and traffic.
IMO, we should make #2 the default, but make the choice between all
three options configurable by the admin (without recompiling Squid).
Let me suggest #4 :
immediately execute an external program that calls gdb or any other debugger
which produces a stack trace of all squid processes and then do #1 or #2.
The stack dumps will be save in an assertion failure log file which admins
can send to Squid developers.
This will speedup the debugging and fixing procedure.
Finally, there must be a mechanism that warns admins that an assertion failure
happened. This is not trivial since an admin does not look every day
in the squid log file.
Marcus
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
