Re: keepaliveNextRequest: abandoning FD

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 11 Nov 2011 10:06:13 -0700

On 11/10/2011 07:11 PM, Amos Jeffries wrote:
> 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.

Understood. Since there were related changes, there is no need to change
the verbosity of the message now. Let's see if those warnings are still
there after they upgrade to more recent v3.2 releases.

Thank you,

Alex.
P.S. The caches in question do not use SslBump AFAIK.
Received on Fri Nov 11 2011 - 17:06:32 MST

This archive was generated by hypermail 2.2.0 : Sat Nov 12 2011 - 12:00:08 MST