Anyone here with knowledge of MPM event?

[Rustam Abdullaev <ru...@gmail.com>]

Hi all,

I need some help with the (experimental) event MPM. I want to extend it to 
support suspendable requests (for comet). Any help is appreciated!

Rusty 

Re: Anyone here with knowledge of MPM event?

[Rustam Abdullaev <ru...@gmail.com>]

>> Is it possible to add some flags to the EOS metadata bucket? For example, 
>> to have a 'continuation' EOS bucket, which would cause the MPM to 
>> 'replay' the original http request after a certain time (or on demand). 
>> In essence there would be 2 separate requests, but they would share the 
>> same connection.
>>
>> To me this looks like a fairly small change to the overall architecture. 
>> Most changes would be inside the Event MPM.
>>
>> Thoughts? Is this possible?
>
> What you are describing is HTTP Keep Alive[1], and the Event MPM already 
> does this :-)

Yes, it's similar to keep-alive, but different. Sorry, my explanations were 
not clear enough. To the client this must look like 1 http request, but in 
the server it would span 2 requests.

With keep-alive we have:

1. http request #1
2. http response #1
3. wait (client decides how long)
4. http request #2
5. http response #2
...

What I want is:

1. http request #1
2. client receives nothing back (response #1 is suppressed)
3. wait (Server decides how long)
4. server internally re-plays request #1 as if it was sent from the client 
for the 2nd time (it wasn't)
5. http response #2

So, I want steps 1,2 and 4,5 to be in two different requests, so that the 
long wait does not consume a thread. For this to work the server would have 
to save and "re-play" the original http request in step 4. And suppress a 
response in step 2.

Hope this clears up my idea a bit. I don't think the event MPM can do this 
without modification.

More details on Comet can be found here:
http://code.google.com/p/google-web-toolkit-incubator/wiki/ServerPushFAQ

- Rustam - 

Re: Anyone here with knowledge of MPM event?

[Paul Querna <ch...@force-elite.com>]

Rustam Abdullaev wrote:
> "Paul Querna" <ch...@force-elite.com> wrote in message 
> news:48CE1EBE.90900@force-elite.com...
>> The event mpm is likely the right place to start since it already have a 
>> concept of suspendable 'conections', but how it is done is specific to 
>> HTTP., However, the problems with making a suspendable *request* are much 
>> deeper in the other parts of the core, and less of a problem in the MPMs.
>> ...
> 
> Thanks for the info! Now that I think about it, I could actually live with 
> suspendable connections (not requests).
> 
> Is it possible to add some flags to the EOS metadata bucket? For example, to 
> have a 'continuation' EOS bucket, which would cause the MPM to 'replay' the 
> original http request after a certain time (or on demand). In essence there 
> would be 2 separate requests, but they would share the same connection.
> 
> To me this looks like a fairly small change to the overall architecture. 
> Most changes would be inside the Event MPM.
> 
> Thoughts? Is this possible? 

What you are describing is HTTP Keep Alive[1], and the Event MPM already 
does this :-)

-Paul

[1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Re: Anyone here with knowledge of MPM event?

[Rustam Abdullaev <ru...@gmail.com>]

"Paul Querna" <ch...@force-elite.com> wrote in message 
news:48CE1EBE.90900@force-elite.com...
>
> The event mpm is likely the right place to start since it already have a 
> concept of suspendable 'conections', but how it is done is specific to 
> HTTP., However, the problems with making a suspendable *request* are much 
> deeper in the other parts of the core, and less of a problem in the MPMs.
> ...

Thanks for the info! Now that I think about it, I could actually live with 
suspendable connections (not requests).

Is it possible to add some flags to the EOS metadata bucket? For example, to 
have a 'continuation' EOS bucket, which would cause the MPM to 'replay' the 
original http request after a certain time (or on demand). In essence there 
would be 2 separate requests, but they would share the same connection.

To me this looks like a fairly small change to the overall architecture. 
Most changes would be inside the Event MPM.

Thoughts? Is this possible? 

Re: Anyone here with knowledge of MPM event?

[Paul Querna <ch...@force-elite.com>]

Rustam Abdullaev wrote:
> Hi all,
> 
> I need some help with the (experimental) event MPM. I want to extend it to 
> support suspendable requests (for comet). Any help is appreciated!
> 


Hi Rustam,

Funny that you mention suspendable requests, I've been thinking about it 
for other reasons recently :-)

The event mpm is likely the right place to start since it already have a 
concept of suspendable 'conections', but how it is done is specific to 
HTTP., However, the problems with making a suspendable *request* are 
much deeper in the other parts of the core, and less of a problem in the 
MPMs.

The first major problem is the filter stack and how handlers are invoked.

A content handler, writes to the filter stack directly, each filter 
invokes the next in the chain, from within its own function.

A filter can choose to buffer, or do whatever it likes with the content.

When a handler is done, it inserts an EOS bucket, which is supposed to 
tell all filters to flush, since it is the end of the current request.

I think the first step, which while complicated, might be the easiest 
way to demo this, is to make a custom static file handler, which would 
write the file at a constant bitrate, ie, 500 kbs.

To do this you would write a file bucket of X length, insert a 'fake' 
EOS, and write it like normal.  You would also have a custom filter that 
would remove the early EOS before it hit the core network filter.  Once 
the first 'pulse' happens, you would then suspend the request for Z 
milliseconds, and modify the event mpm to re-invoke the handler at the 
desired time.

I think the easiest way would be to add a return value from the handler, 
  SUSPEND, which the core would then not do anything extra with, 
assuming that the MPM will call the handler again at the desired time. 
Inside the handler, you would have for example, something like this:

  ap_mpm_query(AP_MPM_SUSPEND_REQUESTS, &sr);

  if (sr) {
    ap_mpm_suspend_request(r, your_function_callback, void_baton, 200ms);
    return SUSPEND;
  }
  else {
    return run_request_as_normal();
  }


Thats my basic thoughts, assuming you don't want to rewrite the entire 
filter chain, which is something I've been trying to avoid :-)

Thoughts?

Paul