tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject [PROPOSAL] More Non-Non blocking NIO crap
Date Thu, 26 Oct 2006 23:11:46 GMT
gents, so I finally think I have a stable NIO implementation that is 
doing fairly well.

I have an idea for a next generation of the NIO connector that I wanted 
to present so that you can comment and if you'd like help out with.


Current Implementation
* Non blocking until the entire request has been received
* Blocking for servlet read
* Blocking for servlet write

Suggested implementation
* Non blocking until the entire request has been received(same as above)
* Blocking for servlet read (same as above)
* Non blocking for servlet write (new feature)

This feature is very much like the SENDFILE feature for static content, 
but will
work with dynamic content and keep alive connections.
Of course this could work as a java sendfile for static content as well.

Thread reduction, as each worker thread only spends the time it takes to 
generate the data.
Thread count no longer is tied to concurrent requests being handled/written
Slow clients will no longer tie up server threads

Ability to have a pluggable "data pool" ie, to avoid running over the 
java heap with data to be written,
this component can be pluggable with one that writes to disk, and can be 
made fairly intelligent.

Much more memory consumption, and I mean much much more if the data pool 
is pure in memory

Where some work needs to be done
Decouple the InternalXXXOutputBuffer from the socket, to write to a 
memory pool of data to be written
Register the memory pool for writes to a shared selector, same way we 
poll for reads
Recycling the request/response object pair can no longer be done at the 
end of the thread, instead it is done when the data write has completed
When the write is complete, the writer thread re-register the connection 
for READ making it ready for the next request if keep alive is requested.
Should be configurable when to use a blocking write(today) vs a non 
blocking write(proposal)
Need to consider how this would work with Comet stuff

I believe this to be a pretty cool idea, and that could work out to 
greatly increase the scalability of tomcat. Implementing this thread 
count will no longer be an issue and the ratio threads to connections 
will dramatically change.

I wont be making any commits to trunk on this, as I don't wanna 
jeopardize our 6.0 release. However, if there are people that wanna work 
on this as a team, we could do something inside Tomcat's sandbox.

Ok dokie dudes and dudettes, that's all for now


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message