[squid-dev] Alternate origin server selection

[Alex Rousskov]

On 10/29/21 9:57 AM, Steve Hill wrote:

> Ok, I've gone back and looked over my old debug logs.  It appears what
> was actually happening was:
> 
> - Client sends "CONNECT www.google.com:443".
> - Connection with TLS made to forcesafesearch.google.com.
> - Client sends "GET / HTTP/1.1\r\nHost: www.google.com"
> - Squid runs the peer selector to find peers for www.google.com (i.e.
> the host contained in the GET request).
> - It finds the appropriate pinned connection:
> client_side.cc(3872) borrowPinnedConnection: conn28
> local=81.187.83.66:52488 remote=216.239.38.120:443 HIER_DIRECT FD 18
> flags=1
> - Squid then logs:
>   FwdState.cc(472) fail: ERR_ZERO_SIZE_OBJECT "Bad Gateway"
>           https://www.google.com/
>   FwdState.cc(484) fail: pconn race happened
>   FwdState.cc(494) fail: zero reply on pinned connection

The above looks like a persistent connection race, way after SslBump
bumped the connections. This kind of races seem unrelated to everything
we have discussed on this thread so far, but I may be missing something.


> Unfortunately, I cannot reproduce this problem now.

Well, if you want to reproduce it, you probably can do that using a
custom origin server, but I do not see the point: There is nothing
particularly "wrong" in the above sequence AFAICT; races happen.
However, it is possible that the above log is lying or misleading, and
there was actually a different problem, a problem related to previous
discussions, but it manifested itself as ERR_ZERO_SIZE_OBJECT "pconn
race happened" diagnostic.


> I can remove the unpinning code and submit a new pull request, which now
> works ok for me.  But I'm very wary that I did originally have problems
> with that which I can no longer reproduce.

Unfortunately, I did not have a chance to study the rejected pull
request before it was rejected, so I cannot advise you on whether
subtracting something from that pull request will result in changes that
should be, in principle, accepted.

I suggest to imagine that the rejected pull request did not exist
(instead of using it as a starting/reference point) and then describe
the problem and the proposed solution from scratch. You can do that here
or via a new pull request. The best avenue may depend on whether your
code changes alter some key Squid principles. If they do, it might be
best to get an agreement on those changes here, but GitHub discussions
have better access to code and better formatting abilities.


Cheers,

Alex.