On 06/30/2017 12:18 PM, Yann Ylavic wrote: > Hi Luca, > > [better/easier to talk about details on dev@] > > On Fri, Jun 30, 2017 at 11:05 AM, <bugzi...@apache.org> wrote: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=60956 >> >> --- Comment #11 from Luca Toscano <toscano.l...@gmail.com> --- >> Other two interesting trunk improvements that have not been backported yet: >> >> 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. > >> >> After a bit of thinking it seems to me that we'd need to find a solution that >> prevents the mod_ssl_output filter to block, but in a safe way. > > IMHO mod_ssl shoudn't (BIO_)flush unconditionally in > modssl_smart_shutdown(), only in the "abortive" mode of > ssl_filter_io_shutdown().
I think the issue starts before that. ap_prep_lingering_close calls the pre_close_connection hook and modules that are registered to this hook can perform all sort of long lasting blocking operations there. While it can be argued that this would be a bug in the module I think the only safe way is to have the whole start_lingering_close_nonblocking being executed by a worker thread. Regards Rüdiger
