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
Irving, Dave wrote:
Remy Maucherat wrote:
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 r
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
Irving, Dave wrote:
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.
The lower level code doesn't deal with IS/OS constructs, only with byte
arrays.
- It looks like I'll have to implement
> 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
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
