Interactions with org.apache.coyote.Request/Response

[Irving, Dave]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Irving, Dave]

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

I'll take a look at how this is done in tomcat at the moment.

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

That's handy. The thing that's currently puzzling me a little is that the 
Response seems to have an associated stream, but doesn't really write to it 
itself. When should I actually go about pushing stuff in to that buffer at the 
connector level? In response to action call-backs?

>>  - 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 ;)

I was asking more about whether the existing CoyoteAdapter is likely to be 
re-usable in such a scenario

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

Sure, there's no way I could see this being included in Tomcat "proper". Like I 
said, its just a prototype to see if it solves a specific problem im 
experiencing (I just cant configure tomcat with 20,000 threads).
However, your reply confuses me somewhat. These are not going to be small 
requests / responses: In fact, they are likely to be fairly large multi-part 
messages (SOAP and the like). In addition, the processing latency is going to 
be large (potentially up to 15 seconds per request).
Surely this is a reason ** for ** breaking the thread per connection model?
Why would it break with anything other than small requests and responses? 
(There's nothing to stop parsing to be offloaded to a small - probably CPU 
count matched - thread pool)?

Would appreciate clarification on this issue - as if Im following a doomed 
route then it would be great to know as early on as possible :o)

> Rémy

Thanks for your time,

Dave


-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: 
[EMAIL PROTECTED]



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Irving, Dave]

Remy Maucherat wrote:

> A thread will still be needed to run the servlet, so I hope the amount
of time 
> spent in the service method will be lower than 15 seconds. Otherwise,
there's 
> no real solution besides having a large amount of threads. 

Yeah, that's the crux of it I suppose. Do you know how much of tomcat
assumes single thread request / response? After the request pops out of
tomcat (via axis), the processing on our side is already asyncronous:
- Receive request
- Pass request on for asyncronous processing
- Internal request processing completes
- Unblock tomcat thread, allowing response to be handled back
through axis and tomcat

I appreciate that dealing with axis to handle asyncronous responses is
out of the scope of this list, but what about tomcat?
Would much need to be changed to remove the assumption that everything
has been done when servicing the servlet returns? I.e: If I can make my
web-apps behave asyncronously, would a whole load need to be done within
tomcat to support this?


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Irving, Dave]

Remy Maucherat wrote:

> I think the conclusion is that your requirements are outside the use
cases for which 
> the servlet API was designed for, so besides reusing portions of the
code, most of 
> your request processing cannot quite run inside the main servlet
container.

Yes - and after doing a bit more reading around the net, it seems that
this is indeed the general consensus.
It would appear that some great minds have spent some serious time
trying to see how this model could work - and have decided that it just
isn't going to. And Im not going to argue with them :o)

Fortunately, it turns out that ditching tomcat for this particular
use-case isn't such a bad thing. We just use the messaging model of axis
(not RPC), so do much of the parsing ourselves.
So, time to throw out the servlet API and Axis (proper) and have
asyncronous request / response processing, re-using axis to convert the
input stream to SOAP objects for us.

I think that is going to be far easier to pull that off than what I was
proposing before - which Im now beginning to appreciate was a bit crazy.

Will still be using tomcat in other areas though - its superb.


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [sales #595323]: test

[Irving, Dave]

Is someone going to get this kicked off.???
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 10 January 2006 12:50
To: tomcat-dev@jakarta.apache.org
Subject: [sales #595323]: test

Dear Mark/Space Customer,

Thank you for your email to our sales department. 


---

This email is an auto-reply to your email and only acknowledges that we
have received your email request for pre-sales information. We will be
replying personally to your email in the order that it was received. We
strive to reply within one business day. If you have written us over the
weekend or during a holiday, we will reply on the next business day.  

Please refrain from sending multiple emails addressing the same question
as this may cause more delays. 



For registration code assistance, please go to:

http://www.markspace.com/resend-codes.php




To purchase a product directly from Mark/Space:

Online Store: 

Store Policies: 

Mark/Space accepts most major credit cards (Visa, MasterCard/EuroCard,
Amex, Discover/Novus). 

Mark/Space does not accept PayPal. 

Mark/Space does not accept institutional or individual purchase orders. 

For information on site licensing or purchases of more than 5 copies of
The Missing Sync, please contact Sales at [EMAIL PROTECTED] 




NOW SHIPPING -- MISSING SYNC FOR PALM OS version 5.

Missing Sync for Palm OS, version 5 is a free upgrade to those who
purchased Missing Sync for Palm OS on or after October 1, 2005. It is a
$24.95 paid upgrade for those who purchased prior to October 1, 2005.

For upgrade information, visit:

http://www.markspace.com/palmosupgrade.php

For those who are not upgrading, purchase at our store:

http://store.markspace.com

Missing Sync for Palm OS version 5 adds many new features. In
particular, Mac OS 10.4 users will be able to use the new Mark/Space
Conduits for Contacts, Events and Tasks. Say goodbye to the iSync Palm
Conduit. For product information, visit:

http://www.markspace.com.missingsync_palmos.php

WHAT DEVICES ARE SUPPORTED BY THE MISSING SYNC FOR PALM OS version 5?

For a complete list of supported devices, please go to:

http://www.markspace.com/missingsync_palmos_devs.html



WHAT'S HAPPENING WITH THE MISSING SYNC FOR WINDOWS MOBILE?

The Missing Sync for Windows Mobile version 2.0.2  is now available! 

For more information, please visit the product page at:



For a list of supported devices and supported operating systems, see:



PLEASE NOTE: Missing Sync for WIndows Mobile does not presently support
Windows Mobile 5 devices. We will be adding support. To learn when it is
available, sign up for our announcement list at:



Need to upgrade from The Missing Sync for Pocket PC to The Missing Sync
for Windows Mobile? 






NEED TO CHANGE YOUR EMAIL ADDRESS IN OUR DATABASE?

Customers can submit email address changes automatically. To change your
email address in our database, please go to: 






We maintain an ONLINE SUPPORT CENTER WITH A SEARCHABLE KNOWLEDGEBASE!

Please visit:



You can review Knowledgebase articles by product or by performing a
keyword search of our entire knowledgebase for specific information. 





Thanks again for your support and your interest in Mark/Space products!

Sincerely,

Mark/Space Sales

-
Mark/Space, Inc.
www.markspace.com   
654 N. Santa Cruz Ave. #300
www.markspace.com/support  
Los Gatos, CA 95030  


-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED] F

RE: [sales #595323]: test

[Irving, Dave]

Yeah - sorry :o) 
I guess my recently acquired insanity temporarily got in the way of my
manners :o)
I do, of course, mean -- please -- would it be possible to get this
kicked off :o)

-Original Message-
From: Carl Olivier [mailto:[EMAIL PROTECTED] 
Sent: 10 January 2006 12:53
To: 'Tomcat Developers List'
Subject: RE: [sales #595323]: test

PLEASE :) 

-Original Message-----
From: Irving, Dave [mailto:[EMAIL PROTECTED]
Sent: 10 January 2006 12:52
To: Tomcat Developers List
Subject: RE: [sales #595323]: test

Is someone going to get this kicked off.???
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 10 January 2006 12:50
To: tomcat-dev@jakarta.apache.org
Subject: [sales #595323]: test

Dear Mark/Space Customer,

Thank you for your email to our sales department. 


---

This email is an auto-reply to your email and only acknowledges that we
have received your email request for pre-sales information. We will be
replying personally to your email in the order that it was received. We
strive to reply within one business day. If you have written us over the
weekend or during a holiday, we will reply on the next business day.  

Please refrain from sending multiple emails addressing the same question
as this may cause more delays. 



For registration code assistance, please go to:

http://www.markspace.com/resend-codes.php




To purchase a product directly from Mark/Space:

Online Store: <http://store.markspace.com>

Store Policies: <http://store.markspace.com/policy.html>

Mark/Space accepts most major credit cards (Visa, MasterCard/EuroCard,
Amex, Discover/Novus). 

Mark/Space does not accept PayPal. 

Mark/Space does not accept institutional or individual purchase orders. 

For information on site licensing or purchases of more than 5 copies of
The Missing Sync, please contact Sales at [EMAIL PROTECTED] 




NOW SHIPPING -- MISSING SYNC FOR PALM OS version 5.

Missing Sync for Palm OS, version 5 is a free upgrade to those who
purchased Missing Sync for Palm OS on or after October 1, 2005. It is a
$24.95 paid upgrade for those who purchased prior to October 1, 2005.

For upgrade information, visit:

http://www.markspace.com/palmosupgrade.php

For those who are not upgrading, purchase at our store:

http://store.markspace.com

Missing Sync for Palm OS version 5 adds many new features. In
particular, Mac OS 10.4 users will be able to use the new Mark/Space
Conduits for Contacts, Events and Tasks. Say goodbye to the iSync Palm
Conduit. For product information, visit:

http://www.markspace.com.missingsync_palmos.php

WHAT DEVICES ARE SUPPORTED BY THE MISSING SYNC FOR PALM OS version 5?

For a complete list of supported devices, please go to:

http://www.markspace.com/missingsync_palmos_devs.html



WHAT'S HAPPENING WITH THE MISSING SYNC FOR WINDOWS MOBILE?

The Missing Sync for Windows Mobile version 2.0.2  is now available! 

For more information, please visit the product page at:

<http://www.markspace.com/missingsync_windowsmobile.html>

For a list of supported devices and supported operating systems, see:

<http://www.markspace.com/missingsync_wm_devices.html>

PLEASE NOTE: Missing Sync for WIndows Mobile does not presently support
Windows Mobile 5 devices. We will be adding support. To learn when it is
available, sign up for our announcement list at:

<http://lists.markspace.com>

Need to upgrade from The Missing Sync for Pocket PC to The Missing Sync
for Windows Mobile? 

<http://www.markspace.com/missingsync_wm_upgrade.php>




NEED TO CHANGE YOUR EMAIL ADDRESS IN OUR DATABASE?

Customers can submit email address changes automatically. To change your
email address in our database, please go to: 

<http://www.markspace.com/change-email.php>




We maintain an ONLINE SUPPORT CENTER WITH A SEARCHABLE KNOWLEDGEBASE!

Please visit:

<http://www.markspace.com/support>

You can review Knowledgebase articles by product or by performing a
keyword search of our entire knowledgebase for specific information. 





Thanks again for your support and your interest in Mark/Space products!

Sincerely,

Mark/Space Sales

-

RE: Greg Wilkins' blog on async servlet API

[Irving, Dave]

Interesting article Of course, he missed one other existing
implementation: http://asyncweb.safehaus.org

If you're thinking of getting async services built in to Tomcat, I'd
certainly be interested in jumping on board :o)

D
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Yoav Shapira
> Sent: 18 May 2006 21:24
> To: Tomcat-dev
> Subject: Greg Wilkins' blog on async servlet API
> 
> Hola,
> Just an FYI likely to be of interest to readers of this list:
> 
> Most of you probably read planetapache.org, but in case you 
> didn't, it linked to an interesting post from Greg Wilkins 
> (the Jetty dude) on  a standard API for async servlets (aka 
> servlet continuations):
> http://www.mortbay.com/MB/log/gregw/?permalink=asyncServlets.html
> 
> --
> Yoav Shapira
> Nimalex LLC
> 1 Mifflin Place, Suite 310
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For 
> additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Greg Wilkins' blog on async servlet API

[Irving, Dave]

The asyncweb API is quite different from this approach - and is much less 
"servletty". 
Maybe take a look at the API and see what you think?
All the Java docs are contained in the current release available here:

https://svn.safehaus.org/repos/asyncweb/release/

Dave


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
> Sent: 20 May 2006 00:38
> To: Tomcat Developers List
> Subject: Re: Greg Wilkins' blog on async servlet API
> 
> Costin Manolache wrote:
> > I agree, it's not  very intuitive - but it's still good to 
> understand 
> > it, and maybe learn from what we like and don't like it :-) 
> It's hard 
> > to make something simple, intuitive, easy to implement, high 
> > performance, flexible - all at the same time.
> 
> The javadoc seems quite explicit: you may send the response 
> later (when the "notify" method is called). It's not much 
> (and what is this "key" 
> class all about ??; personally, I also started with an object 
> as an id, but yanked it as it was useless).
> 
> Rémy
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For 
> additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]