implementation of blocking input

[Bill Burke]

I've thought about this alot the past few days:

Basically I'm implementing a servlet container.  The problem is that, as 
you know, a servlet container uses InputStream and OutputStream, and how 
or when the IS or OS is read from or written to is up to the application 
code.  You pretty much have to have a request queue which is worked on 
by a different set of dedicated workers.  With the current way Netty 
works, you basically have to use java.io.Piped streams (or something 
similar) to coordinate between the request queue and the netty 
NIOWorker.  I just don't see a way around it.  My initial idea of 
blocking just won't work as you may starve the other channels being 
managed by the NIOWorker.

With this approach I worry about large input or output.  Either 
operation has to be queued and depending how slow or fast input or 
output is, you could be buffering A LOT of data.  There's also a lot of 
context switching being done between the request

The ideal situation would be for the NIOWOrker to transfer control of 
the channel to the request thread, but this would require a big 
refactoring of Netty.  Basically a rewrite.



On 10/20/11 3:26 AM, ljohnston wrote:
> Hi Bill
>
> Is it possible to elaborate a bit more on the specific problem? For example,
> when you're using an inputstream, how do you determine when you've read the
> bit that you need, what do you do with that data and then how do you process
> the remaining data?
>
> Cheers
> Lee
>
>
> --
> View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/implementation-of-blocking-input-tp6902613p6911899.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com