users@grizzly.java.net

Re: Channel De-registration

From: Ray Racine <ray.racine_at_gmail.com>
Date: Wed, 22 Jun 2011 18:13:27 -0400

Previous explanation was fuzzy I know. Sorry.

See ...

“An Architecture for Highly Concurrent, Well-Conditioned Internet Services”.
http://www.eecs.harvard.edu/~mdw/papers/mdw-phdthesis.pdf

Consider if all stages were Akka / Scala Actors stay with Asynch messaging
between Actors whenever possible.

Ray

On Wed, Jun 22, 2011 at 4:31 AM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> wrote:

> **
> Hi Ray,
>
> just curious,
> why you think Grizzly 2 functionality is not enough for you and why you'd
> like to deregister channel (if it's still the case)?
>
> Anyways you can de-register NIOConnection using method
> NIOConnection.detachSelectorRunner();
>
> WBR,
> Alexey.
>
>
> On 06/21/2011 08:31 PM, Ray Racine wrote:
>
> Never mind below. At least from the context of a NBIO sendfile the 2.0
> grizzly samples could not be clearer.
>
> On Tue, Jun 21, 2011 at 11:36 AM, Ray Racine <ray.racine_at_gmail.com>wrote:
>
>> I'd like to do something along the following lines.
>>
>> 1. Grizzly is embedded inside my application and is started.
>> 2. Client sends HTTP PUT with payload to Grizzly.
>> 3. Griz accepts. Connection may or may not be Non-Blocking. (My
>> configuration choice)
>> 4. My handler reads in the payload from the Request.
>> 5. Handler now takes 100% ownership of the channel.
>> 1. If SocketChannel is NB then de-register from Griz's Selector.
>> 2. If SocketChannel is Blocking then place in non-blocking and
>> ultimately registered with a different Selector.
>> 3. If registered with Griz for other purposes such as timeouts etc,
>> this is also deregistered.
>> 4. i.e. Channel becomes 100% detached from Griz and 100% owned by
>> my Handler.
>> 6. Handler has own selector and thread executor pool.
>> 7. Handler processes payload. (Not long duration, in secs at most)
>> 8. Handler process writes response back on SocketChannel.
>> 9. Handler (maybe with Griz API assistance or unilaterally) performs
>> clean SocketChannel close.
>>
>> I have located the following example figuring it had to be doing
>> something along the lines I wanted. In lines 270 and 280 there appears to
>> the crux of a hand off detachment of a channel from Griz to the handler.
>>
>>
>> http://kenai.com/projects/grizzly-sendfile/sources/main/content/grizzly-sendfile-g20/src/main/java/com/igorminar/grizzlysendfile/SendfileFilter.java?rev=296
>>
>> My questions:
>>
>> 1. Is this sort of thing supported by Griz's API, or is the above
>> example subverting Griz and its a fragile kludge?
>> 2. Not sure if the above example is Griz 1.9.x or 2.0.x oriented? I'd
>> like to do the above strictly in 2.x Grizzly.
>> 3. Is sendfile doing it the "right" way? Is there a better way with
>> the current 2.x API?
>> 4. Anyone have a superior example of how to do this in Grizzly 2.x?
>>
>> Thanks
>>
>> Ray
>>
>
>
>