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.
NIO GEN 2
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)
Explanation
-----------
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.
Goal
----
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
Features
--------
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.
Negatives
---------
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
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
