Hi, Alex,
We have the same “suspension” issue when “too many failure”. See this links.
https://www.mail-archive.com/squid-users@lists.squid-cache.org/msg22187.html
>> 14:24:24 kid1| suspending ICAP service for too many failures
>> 14:24:24 kid1| essential ICAP service is suspended:
We tried enable the debug_options ALL,1 93,7
But have not reproduced suspensions and did not find the root cause.
Checking the source code, can we simply comment out the lines:
scheduleUpdate(squid_curtime + TheConfig.service_revival_delay);
announceStatusChange("suspended", true);
void Adaptation::Icap::ServiceRep::suspend(const char *reason)
{
if (isSuspended) {
debugs(93,4, "keeping suspended, also for " << reason);
} else {
isSuspended = reason;
debugs(93, DBG_IMPORTANT, "suspending ICAP service for " << reason);
scheduleUpdate(squid_curtime + TheConfig.service_revival_delay);
announceStatusChange("suspended", true);
}
}
void Adaptation::Icap::ServiceRep::noteFailure()
{
const int failures = theSessionFailures.count(1);
debugs(93,4, " failure " << failures << " out of " <<
TheConfig.service_failure_limit << " allowed in " <<
TheConfig.oldest_service_failure << "sec " << status());
if (isSuspended)
return;
if (TheConfig.service_failure_limit >= 0 &&
failures > TheConfig.service_failure_limit)
suspend("too many failures");
// TODO: Should bypass setting affect how much Squid tries to talk to
// the ICAP service that is currently unusable and is likely to remain
// so for some time? The current code says "no". Perhaps the answer
// should be configurable.
}
Regards,
John Zhu
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
