<div>Hi Bill,</div><div><br></div><div>You mean switching from non-blocking mode to blocking mode and reading the HTTP content by yourself in blocking manner to implement your InputStream?</div><div><br></div><div>The imaginary code could look like this:</div><div><br></div><div>void messageReceived(ctx, evt) {</div><div> if(evt.getMessage() instanceof HttpMessage) { // no body yet</div><div> nioSocketChannel ch = ctx.getChannel().detach();</div><div> handleBodyInOtherThread(ch);</div><div> }</div><div> ...</div><div>}</div><div><br></div><div>// in other thread..</div><div>ch.configureBlocking(true);</div><div>InputStream in = new ChannelInputStream(ch);</div><div>OutputStream out = new ChannelOutputStream(ch);</div><div>.. do some servlet-ish job ..</div><div>nettyWorker.attach(ch); // attach it back to handle the next request</div><div><br></div><div>Is this what you meant?</div><div><br></div><div>Cheers</div><div><br></div><div><span class="Apple-style-span" style="color: rgb(160, 160, 168); ">On Thursday, October 20, 2011 at 7:00 AM, Bill Burke wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>I've thought about this alot the past few days:<br><br>Basically I'm implementing a servlet container. The problem is that, as <br>you know, a servlet container uses InputStream and OutputStream, and how <br>or when the IS or OS is read from or written to is up to the application <br>code. You pretty much have to have a request queue which is worked on <br>by a different set of dedicated workers. With the current way Netty <br>works, you basically have to use java.io.Piped streams (or something <br>similar) to coordinate between the request queue and the netty <br>NIOWorker. I just don't see a way around it. My initial idea of <br>blocking just won't work as you may starve the other channels being <br>managed by the NIOWorker.<br><br>With this approach I worry about large input or output. Either <br>operation has to be queued and depending how slow or fast input or <br>output is, you could be buffering A LOT of data. There's also a lot of <br>context switching being done between the request<br><br>The ideal situation would be for the NIOWOrker to transfer control of <br>the channel to the request thread, but this would require a big <br>refactoring of Netty. Basically a rewrite.<br><br><br><br>On 10/20/11 3:26 AM, ljohnston wrote:<br><blockquote type="cite"><div>Hi Bill<br><br>Is it possible to elaborate a bit more on the specific problem? For example,<br>when you're using an inputstream, how do you determine when you've read the<br>bit that you need, what do you do with that data and then how do you process<br>the remaining data?<br><br>Cheers<br>Lee<br><br><br>--<br>View this message in context: <a href="http://netty-forums-and-mailing-lists.685743.n2.nabble.com/implementation-of-blocking-input-tp6902613p6911899.html">http://netty-forums-and-mailing-lists.685743.n2.nabble.com/implementation-of-blocking-input-tp6902613p6911899.html</a><br>Sent from the Netty User Group mailing list archive at <a href="http://Nabble.com">Nabble.com</a>.<br>_______________________________________________<br>netty-users mailing list<br><a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/netty-users">https://lists.jboss.org/mailman/listinfo/netty-users</a><br></div></blockquote><br>-- <br>Bill Burke<br>JBoss, a division of Red Hat<br><a href="http://bill.burkecentral.com">http://bill.burkecentral.com</a><br>_______________________________________________<br>netty-users mailing list<br><a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/netty-users">https://lists.jboss.org/mailman/listinfo/netty-users</a><br></div></div></span>
</blockquote>
<div>
<br>
</div>