users@grizzly.java.net

Channel De-registration

From: Ray Racine <ray.racine_at_gmail.com>
Date: Tue, 21 Jun 2011 11:36:27 -0400

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