implementation of blocking input
Trustin Lee
trustin at gmail.com
Thu Oct 20 19:14:54 EDT 2011
Hi Bill,
You mean switching from non-blocking mode to blocking mode and reading the HTTP content by yourself in blocking manner to implement your InputStream?
The imaginary code could look like this:
void messageReceived(ctx, evt) {
if(evt.getMessage() instanceof HttpMessage) { // no body yet
nioSocketChannel ch = ctx.getChannel().detach();
handleBodyInOtherThread(ch);
}
...
}
// in other thread..
ch.configureBlocking(true);
InputStream in = new ChannelInputStream(ch);
OutputStream out = new ChannelOutputStream(ch);
.. do some servlet-ish job ..
nettyWorker.attach(ch); // attach it back to handle the next request
Is this what you meant?
Cheers
On Thursday, October 20, 2011 at 7:00 AM, Bill Burke wrote:
> 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 (http://Nabble.com).
> > _______________________________________________
> > netty-users mailing list
> > netty-users at lists.jboss.org (mailto: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
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org (mailto:netty-users at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/netty-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20111020/e1413eb0/attachment.html
More information about the netty-users
mailing list