Interactions with org.apache.coyote.Request/Response

["Irving, Dave" <da...@logicacmg.com>]

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?
	- 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?
	- Pointers to any documentation I've missed discussing how
org.apache.coyote.Request / Response are interacted with by the rest of
tomcat - and what I should do to ensure that all response output goes to
my ByteArrayOutputStream buffer

Any pointers / help / advice would be gratefully received.

Many thanks,

Dave



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Interactions with org.apache.coyote.Request/Response

[Remy Maucherat <re...@apache.org>]

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?

No.

> 	- 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.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org