we are seeing the same erros in our cache_log 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. there were also a discussion from may this year > tis 2012-05-01 klockan 08:09 -0500 skrev Guy Helmer: >> I'm working with code I obtained from Alex that was sync'ed with trunk as of -r12082 (2012-03-07 v3.2.0.16+) and on a very busy system doing forward HTTP and HTTPS proxy (but not sslBump), I am seeing lots of these messages: >> >> 2012/05/01 08:50:06 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.115:1409 FD 1113 flags=1 >> 2012/05/01 08:50:28 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.125:1356 FD 1024 flags=1 >> 2012/05/01 08:50:28 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.125:1357 FD 1220 flags=1 >> 2012/05/01 08:50:31 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.125:1359 FD 1152 flags=1 >> >> I see that there was a discussion back in November about this issue, but I am not understanding what the root cause is, and whether it is indicative of a serious problem. Any thoughts? > > It would be excellent if you could pair one or two such message with the > network traffic taking place on the client connection (the client is > remote ip:port in the message). > > Regards > Henrik we are using squid 3.2.3 and also with the latest nightly build (squid-3.2.3-20121119-r11700). first we thought this error is some new strange behavior of squid under heavy load. after some testing we found one error cause: we are using ufdbguard, squid.conf: url_rewrite_program /rzf/produkte/www/bin/ufdbguard/ufdbgclient -e allow -C -l/rzf/produkte/www/files/ufdbguard/logs we see this error messages when there was a https-request which is blocked by ufdbguard. when ufdb blocks a request we do a redirect on a http-page to give the user an error response. with https-sites this does and can not work. the browser is expecting a correct ssl answer and waits to get the right ssl-certificate from the origin server, but our http-server does answer either with http and not https and the fqdn is not correct. so in the browser I only see a general "connection error" message, not our blocked script. this is the client side. in the cache_log we get 2012/11/21 13:09:40 kid1| client_side.cc(1602) keepaliveNextRequest: abandoning local=123.45.1.1:8080 remote=123.45.6.7:1988 FD 2247 flags=1 now the question to this long mail: are these errors harmless, do we have to care about them? we have really a lot of these messages. what about open connections, ssl tunnels/connects, ntlm and/or basic authentication handlers. are those connections all get closed cleanly.... mfg Markus Rietzler <rietzler_software/> Rechenzentrum der Finanzverwaltung Tel: 0211/4572-2130
