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
