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