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
>