tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Interactions with org.apache.coyote.Request/Response
Date Tue, 18 Oct 2005 08:46:37 GMT
Irving, Dave wrote:
> Hi,
> Im currently prototyping a NIO connector for tomcat - using tomcat
> 5.0.28 as a base.
> This is to solve a specific issue: We have to support a very high number
> of concurrent connections in a high latency server - and want to remove
> the thread per connection dependency. 
> In particular, for my use, the aim is not to provide any direct
> performance gain over standard tomcat (in fact, it is acceptable for
> actual performance to be less than that of the standard connector).
> This connector doesn't have to support everything tomcat does for http
> (although it will support chunked encoding, persistent connections and
> 100-continue expectations).
> My idea was simple: Read in full HTTP requests upfront using NIO -
> parsing using stateful, piece-meal decoders. We can then offer a
> ByteArrayInputStream up to tomcat as the request stream - which - of
> course - will never block. Tomcat and associated WebApps can "do their
> thing" - with all response data going to an underlying
> ByteArrayOutputStream under the hoods.
> When the request has been fully handled, this can then get written out
> using NIO.
> The idea is to try and fit this in at a low level - so that maximum
> re-use can be made of existing tomcat code.
> Its going well - I've written the parsers and can handle chunked
> encoding or explicit content length, persistent connections (keep-alive
> for http 1.0) and 100-continue expectations.
> What I would really appreciate help with is how best to "slot this in"
> to tomcat code.
> I suppose Im writing a replacement to the
> org.apache.coyote.http11.Http11Processor (without supporting the
> InputFilter stuff I expect).
> It seems that org.apache.coyote.Request / Response are crucial to this.
> What I'd find invaluable would be any information covering the
> following:
> 	- Where should the underlying output-stream be slotted in to
> gather up the response data such that maximum re-use can be made of
> existing tomcat code?

There's no reason to use crap stuff like a BAOS. Just append byte arrays 
to a buffer.

> 	- It looks like I'll have to implement the ActionHook stuff to
> deal with call-backs from the request / response. Is there anything else
> I'll need to do?


> 	- Im planning to have my "NIOHttpProcessor" use a CoyoteAdapter
> the same way the Http11Processor does. Does this sound reasonable
> enough?

I don't care how how you name your classes ;)

> Any pointers / help / advice would be gratefully received.

Obviously, you can feel free to experiment all you want, but such a 
specific connector will not be included in Tomcat. Scalability will be 
far more limited with your design than even with the fully threaded 
Tomcat. If all the server is doing are small requests and responses, 
then it will work well (however, the hybrid model also likes this 
scenario, so I don't think it will even improve on that), otherwise it 
will just break.


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

View raw message