On Fri, Jun 30, 2017 at 12:52 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > 2017-06-30 12:18 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>: >> > >> > http://svn.apache.org/viewvc?view=revision&revision=1706669 >> > http://svn.apache.org/viewvc?view=revision&revision=1734656 >> > >> > IIUC these ones are meant to provide a more async behavior to most of >> > the >> > output filters, namely setting aside buckets (on the heap) to avoid >> > blocking. >> >> These are quite orthogonal I think, and don't seem to fix this particular >> issue. > > Sorry for the noise, I am still reviewing those to understand what they > really do and added them as reference to the task.
NP, it's not really a noise either because with my proposed change they'd imply a different fix for 2.4 and trunk. >> >> With a possibly non-blocking modssl_smart_shutdown(), I think we could >> make ap_shutdown_conn(c, 0) return something like APR_INCOMPLETE for >> the case the shutdown was "buffered" in the output filter stack (e.g. >> core output filter). >> >> In mpm_event, we would then go to (or stay in) the WRITE_COMPLETION >> state instead of LINGER, until every remaining piece data is flushed >> successfully. > > IIUC in this case the listener is calling > process_timeout_queue(write_completion_q, ..), so the conn has already been > in the WRITE_COMPLETION state for Timeout seconds and needs to be closed. > Your suggestion would be to still force the listener to call > ap_shutdown_conn(c, 0), but a "smarter" version that eventually returns > APR_INCOMPLETE rather than blocking. Then the listener could put the > connection again in the WRITE_COMPLETION queue, and wait for the client to > unblock and read the missing bytes about close-notify (or just let Timeout > seconds to pass, forcing the listener to shutdown the socket and be done > with it). We'd use a shorter timeout but that was the idea yes. But nevermind, I like Rüdiger's idea better actually, less invasive (I think) and more bullets proof. Continued there...
