[Paperclips-discuss] non-blocking io and paperclips: some thoughts

[Nic Ferrier]

I've been thinking about this a lot over the last few days.


Currently Paperclips maps a thread to a request. nbio suggests worker
thrreads being used by the main selector loop.

With HTTP there isn't much of a big deal about reading from the
socket... the stream will probably only contain the header and
possibly some POSTed content. 

Only when there's a file upload or some SOAPy protocol is used over
HTTP is any significant transfer to the webserver performed.

This means it should be possible, as Chris suggested, to buffer the
incomming reads and when the data is complete dispatch to the
servlet.

Not too much nbio-ing will occur because the amount of data is so
small.

When the data is more complex than the usual GET or POST (check the
content-type as we read the header in) we could read just the header
and then pass the inputstream to a blocking thread to do the rest.
That's seems to be a matter of just removing the read channel from the
selector when you've read the header.

Output from Paperclips is much more likely to block because there's
generally more of it.

non-blocking output I'm sure can be done inside the stream classes
Paperclips provides to servlets. Of course some buffering must occur
but Paperclips is doing chunk buffering so the chunk buffers could be
reused as nbio buffers.

But there's still the issue of how to distribute processing time to
requests.

Once the header has been read the select loop needs to process the
request (possibly with writes being nbio'd through the chunk stuff).

The select loop cannot simply call the servlet once it has recieved
the header because the servlet might block and stop the whole server.

Alter alternately using one thread for each servlet reduces the point
of the nbio stuff, even if you're doing nbio on writes it's not going
to gain you any performance, in fact it's the worst of both worlds.

But one way it might be possible is to abandon the concept of
multi-processing.

When the header has been read find the servlet associated with the
header and ask a free thread to service it. 

join(timeout) on the thread. If you manage to join the thread then
the servlet has finished and you can go onto the next request.

If timeout occurs then loop round again leaving the thread running.
When you've gone round once come back to the thread and try and join
it again.

In a real implementation you wouldn't use join of course, but some
signal that the select thread could wait(timeout) on and check.

This is much closer to the spirit of non-blocking servers, but
unfortunately it's not perfect because it's not using the blocking of
io back to the socket as the yield condition.


Nic