What is a "clogging" input filter?

[Graham Leggett <mi...@sharp.fm>]

Hi all,

Currently mod_ssl doesn't work with the event MPM, as per the following code:

    if (c->clogging_input_filters && !c->aborted) {
        /* Since we have an input filter which 'cloggs' the input stream,
         * like mod_ssl, lets just do the normal read from input filters,
         * like the Worker MPM does.
         */
        apr_atomic_inc32(&clogged_count);
        ap_run_process_connection(c);
        if (cs->pub.state != CONN_STATE_SUSPENDED) {
            cs->pub.state = CONN_STATE_LINGER;
        }
        apr_atomic_dec32(&clogged_count);
    }

Can anyone explain what it means exactly to clog the input stream?

Am I right in understanding that openssl reads ahead, and therefore there may not be data for reading when we get to apr_pollset_poll()?

Or is this instead to do with openssl returning SSL_ERROR_WANT_READ during SSL_write? (and vice versa)?

Regards,
Graham
--

Re: What is a "clogging" input filter?

[Jim Jagielski <ji...@jaguNET.com>]

In process_socket() when we create cs, should we explicitly
set cs->pub.sense to CONN_SENSE_DEFAULT?

Otherwise, +1 (with a mmn bump).

On Apr 19, 2013, at 6:09 PM, Graham Leggett <mi...@sharp.fm> wrote:

> On 19 Apr 2013, at 6:38 PM, Eric Covener <co...@gmail.com> wrote:
> 
>>> What would it take to make mod_ssl a non-clogging filter?
>> 
>> Basically needs two things:
>> 1) Never buffer data inside ssl (feasible I believe)
>> 2) Create a new way for a filter deep inside the chain to indicate we
>> need to wait for a read/write ability on a socket -- this
>> fundamentally is why a Serf bucket model is better than our chained
>> filters.  An alternative  approach would be changing the flow so
>> filters don't directly call the next filter, putting the core back in
>> control of filter flow, but this is still a non-trivial project.
> 
> Would something like the attached patch work?
> 
> Looking closer at mod_ssl, it seems that when it writes, it wires in both the input and output filter stacks, which is good, but when it reads, only the input filter stack is wired in, which means it can never write. This might need to be looked at too.
> 
> Regards,
> Graham
> --
> <httpd-unclog.patch>

Re: What is a "clogging" input filter?

[Graham Leggett <mi...@sharp.fm>]

On 19 Apr 2013, at 6:38 PM, Eric Covener <co...@gmail.com> wrote:

>> What would it take to make mod_ssl a non-clogging filter?
> 
> Basically needs two things:
> 1) Never buffer data inside ssl (feasible I believe)
> 2) Create a new way for a filter deep inside the chain to indicate we
> need to wait for a read/write ability on a socket -- this
> fundamentally is why a Serf bucket model is better than our chained
> filters.  An alternative  approach would be changing the flow so
> filters don't directly call the next filter, putting the core back in
> control of filter flow, but this is still a non-trivial project.

Would something like the attached patch work?

Looking closer at mod_ssl, it seems that when it writes, it wires in both the input and output filter stacks, which is good, but when it reads, only the input filter stack is wired in, which means it can never write. This might need to be looked at too.

Regards,
Graham
--

Re: What is a "clogging" input filter?

[Eric Covener <co...@gmail.com>]

On Fri, Apr 19, 2013 at 11:14 AM, Graham Leggett <mi...@sharp.fm> wrote:
> Hi all,
>
> Currently mod_ssl doesn't work with the event MPM, as per the following code:
>
>     if (c->clogging_input_filters && !c->aborted) {
>         /* Since we have an input filter which 'cloggs' the input stream,
>          * like mod_ssl, lets just do the normal read from input filters,
>          * like the Worker MPM does.
>          */
>         apr_atomic_inc32(&clogged_count);
>         ap_run_process_connection(c);
>         if (cs->pub.state != CONN_STATE_SUSPENDED) {
>             cs->pub.state = CONN_STATE_LINGER;
>         }
>         apr_atomic_dec32(&clogged_count);
>     }
>
> Can anyone explain what it means exactly to clog the input stream?
>
> Am I right in understanding that openssl reads ahead, and therefore there may not be data for reading when we get to apr_pollset_poll()?
>
> Or is this instead to do with openssl returning SSL_ERROR_WANT_READ during SSL_write? (and vice versa)?
>

I have this starred response from Paul Querna in my gmail:

-----------------
It means the filter buffers in such a way that it might have data
inside it, but a poll() on the socket will never return active when it
has data ready.  It also has to do with filters that change the
read/write flow -- we currently don't have a way for an output filter
for example to say "come back to me when there is data available to
READ".  This is specifically the mod_ssl problem, because of the SSL
protocol, you often need to do a write before you can read, or vice
versa.

> What would it take to make mod_ssl a non-clogging filter?

Basically needs two things:
1) Never buffer data inside ssl (feasible I believe)
2) Create a new way for a filter deep inside the chain to indicate we
need to wait for a read/write ability on a socket -- this
fundamentally is why a Serf bucket model is better than our chained
filters.  An alternative  approach would be changing the flow so
filters don't directly call the next filter, putting the core back in
control of filter flow, but this is still a non-trivial project.
------------




--
Eric Covener
covener@gmail.com