[Web-SIG] Container buffering of output.

[Alan Kennedy]

[Alan Kennedy]
 >> In  .. J2EE .. the container will do it's own buffering completely
 >> outside your control, and send the pieces with chunked-transfer
 >> encoding if necessary. So even if I put a flush on the output channel
 >> in my framework, I'm only flushing it to the container's buffer: it's
 >> still not guaranteed to send output back down the return socket to the
 >> client.

[Phillip J. Eby]
 > That is potentially a problem, since the point is to guarantee that when
 > 'write()' returns to the application, the output isn't going to just sit
 > in the buffer while the application moves ahead with other things: it
 > should be going to the client.

Hmmm, I don't see how it would be a problem. Although I suppose that 
depends on what you mean by "the output isn't going to just sit in the 
buffer": which buffer?

As you say, when the write() returns, the application's output has been 
sent as far as I can send it. My entire thread of execution for a 
request may have ended, and the output may still be sitting in some 
container's (i.e. Apache, Tomcat) buffer, i.e. not sent to the client: 
there's nothing I can do about that. I can call flush on my 
OutputStream, but I can't guarantee that the container will respect that 
by actually flushing to the client, for whatever reasons it may have.

This already happens with plain CGI. That's the way that containers like 
Apache and Tomcat deal with most dynamic content: buffer CGI/etc output 
until the buffer is full, then send a chunk to the client.

The behaviour of the container will probably be different if a 
Content-Length header is set: it might pass the output straight through, 
or it might still buffer it. That's container-specific.

This is all an inevitable consequence of running inside a container of 
some kind.

However, if the container were written in python, e.g. SimpleHttpServer, 
Medusa or Twisted, they could meet the guarantee "sent down the socket 
to the client before the write() returns", because they hold the socket 
connected to the client. He who holds the socket calls the shots.

I don't see any of this presenting a problem for WSGI.

Regards,

Alan.