Hi Willy, Good to know it was fixed. I will try to do some more testing as well.
btw: do you mind if I am trying to have the SOCKS4 support backported to 1.9 and 1.8? Thank you. Regards, Alexander Liu On Mon, Jun 3, 2019 at 2:42 PM Willy Tarreau <[email protected]> wrote: > > On Mon, Jun 03, 2019 at 07:19:46AM +0200, Willy Tarreau wrote: > > On Mon, Jun 03, 2019 at 01:40:28AM +0800, Alec Liu wrote: > > > Hi Willy, > > > > > > Your configuration working for me too, but once I have the "mode tcp" > > > changed to "mode http", it was failed. > > > Can you give it a try by changing your testing configuration mode from > > > "mode tcp" to "mode http"? > > > > OK I can now reproduce it this way. And I'm seeing the same problem > > you have regarding epoll_ctl(DEL). I'm anticipating something ugly > > in the lower layers now... > > So as I feared it, it was ugly, but not that much in the end. The problem > stemmed from long ago due to handshake handlers partially dealing for their > events and for others', leaving the connections in a pseudo-random polling > state. And the reason it failed in HTTP mode was because mux-h1 immediately > tries to recv() after a connect(), fails, then subscribes the connection to > polling marking it not ready, then the handshake handlers use this not-ready > mark to stop processing, and did not even enable polling for recv when > leaving, which explains the EPOLL_CTL_DEL you've seen. > > I've fixed the connection issues and also have a working fix for mux-h1 that > I'll ask Christopher confirmation before merging it. > > Now everything works for me, tcp/http, proxy v1/v2/none, with or without > socks4, with or without checks. > > Cheers, > Willy
