https://bz.apache.org/bugzilla/show_bug.cgi?id=56188
--- Comment #23 from Luca Toscano <[email protected]> --- Hi Yann! I took some notes in this task without adding too many info, my bad. I am currently trying to understand if the method used to detect a client disconnect (i.e. poll() the client TCP connection for POLLIN events) can lead to bugs or performance regressions. Following up inline: (In reply to Yann Ylavic from comment #22) > (In reply to Luca Toscano from comment #21) > > > > 1) Would we get a EOF even when the client's TCP connection is in a state > > like half-closed? (So basically doing a correct shutdown). > > Half-closed by whom (and which way)? > > A shutdown() for write sends a FIN to the peer, so a poll() there would > return with POLLIN and/or POLLHUP (depending on the system), and > read()/recv() returns 0 (EOF). > It's still possible to poll()/read() an half-closed connection (shut down > for write only), hence wait for the peer's data or FIN (read only > connection). > > A shutdown() for read is not "visible" remotely, so it actually has little > value (i.e. just stop reading). > > But I don't know how you'd like to use half-closing, so please clarify ;) My question was if there was any corner case in which if, after a client has initiated a TCP connection close, mod-proxy-fcgi wrongly assume that the connection dropped (because of POLLIN and EOF) taking its own remediation (error logs, etc..). > > > > 2) How many times is the POLLIN (registered to on the client's TCP > > connection to detect disconnects) case executed for a "typical" POST > > request? It seems like that code would get triggered for every incoming > > group of bytes. > > Yes, poll() is woken up for each piece of data (or FIN) available in the > socket, and until there is nothing more to read immediately (i.e. unless > subsequent recv()s empty the socket, poll() won't block). > > So it depends on the size of the buffer used for reading, or if multiple > nonblocking reads will empty the queue. In this case I am wondering if my patch would introduce a performance regression for use cases like big requests coming in (like POSTs for example). We don't really care about reading those bytes (in the code introduced by my patch) but only to check if the connection with the client is still up, so there might be a better way to approach the issue. Let me know if my questions are clearer or if you need more info! :) (Or if I need to study more the subject!) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
