Re: keepaliveNextRequest: abandoning FD

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 11 Nov 2011 15:11:52 +1300

On 11/11/2011 11:01 a.m., Alex Rousskov wrote:
> Hello,
>
> I see thousands of these messages on busy caches:
>
>> 2011/11/07 05:16:23 kid1| client_side.cc(1573) keepaliveNextRequest: abandoning FD 6650
>> 2011/11/07 05:16:27 kid3| client_side.cc(1573) keepaliveNextRequest: abandoning FD 9180
>> 2011/11/07 05:16:28 kid5| client_side.cc(1573) keepaliveNextRequest: abandoning FD 6361
>> 2011/11/07 05:16:28 kid6| client_side.cc(1573) keepaliveNextRequest: abandoning FD 3322
>> 2011/11/07 05:16:31 kid2| client_side.cc(1573) keepaliveNextRequest: abandoning FD 7809
>> 2011/11/07 05:16:32 kid3| client_side.cc(1573) keepaliveNextRequest: abandoning FD 121
> The code says:
>
>> // XXX: Can this happen? CONNECT tunnels have deferredRequest set.
>> debugs(33, DBG_IMPORTANT, HERE<< "abandoning "<< conn->clientConnection);
>
> So, the answer to that XXX question is "yes, it can happen", at least in
> older v3.2 code. Does anybody know whether there were any recent changes
> that were meant to address the above?

Yes the ConnStateData::stopReading() was moved to only happen when about
to call tunnelStart() in client_side_request.cc instead of all CONNECT
method requests.

CONNECT assumes full control over the connection, but ssl-bump uses the
ConnStateData.

>
> Can we raise the debugging level away from DBG_IMPORTANT now that we
> know the answer?

Well, we know the answer. The problem is still a big huge bug somewhere
if it ever gets hit though. They seemed not to occur at all once the
ssl-bump case of CONNECT was taken care of.

Amos
Received on Fri Nov 11 2011 - 02:12:03 MST

This archive was generated by hypermail 2.2.0 : Fri Nov 11 2011 - 12:00:10 MST