[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: keepaliveNextRequest: abandoning FD
From:       Amos Jeffries <squid3 () treenet ! co ! nz>
Date:       2011-11-12 11:15:49
Message-ID: 4EBE5565.2070803 () treenet ! co ! nz
[Download RAW message or body]

On 12/11/2011 6:06 a.m., Alex Rousskov wrote:
> 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.

K. Same fix resolved the NTLM and a lot of other problems as well. You 
or whoever could be hitting any one of those known and unknown bugs. The 
core problem was  that parser cleared the reader way too early in older 
versions, so any reason for early response was treated as a completed 
CONNECT request after that response was sent, even if the tunnel was 
never started (so never got to cleanup).

Amos
[prev in list] [next in list] [prev in thread] [next in thread]