implementation of blocking input

[Bill Burke]

I was looking a bit at XNIO which supports this sort of thing.  What 
they do is suspend reads in the current channel's selector by setting 
the interest-ops to 0.  Then he uses a different polling selector 
("sun.nio.ch.PollSelectorImpl") and registers the channel with it for a 
short period to do the blocking:



On 10/20/11 7:14 PM, Trustin Lee wrote:
> 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
>
>
>
> _______________________________________________
> 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