Re: keepaliveNextRequest: abandoning FD

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
Received on Sat Nov 12 2011 - 11:16:11 MST