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
