Was some off the cuff thinking.
Current app is in Scala and uses Actors + Grizzy 1.9.x Sort of a SEDA
approach with everything non-blocking. Except for the Grizzly I/O side
which is currently configured with the ol' standard HTTP 1 thread per
request.
My thought on going to Gizzly 2.0 was to go full SEDA across the board with
Actors. My (too) quick a glance at the Griz 2.0 arch, which is very nice
and much improved, got me thinking that when I walked down the fliter chain
I need to walk back up as well. So I either need to suspend the chain go do
something asynchronously and then get back to the chain and resume it
somehow. Or I just jump out of the chain and never come back. Sort of CPS
style.
So with the second approach I was mulling I would never "return" to the
filter chain. In fact all processing would be async. Accept the
connection -> HTTP Filter -> Detach Socket Channel -> Send Msg with Channel
to Actor 1 -> m1 -> Actor 2 -> m2 -> Actor 3 -> ... -> mn -> Actor N where
Actor N would write the response to the detached channel contained within
the message it received. In this case the last Actor has no means to get
back to the filter chain.
Another thought was to "suspend" the chain and have it wait on a Future, or
create a call-back Actor 0, i.e. setup some resuming "event". So say I
create and Actor and suspend the chain. Then I can pass this call-back
Actor down the Actor chain. The last actor, Actor N, responds to the
call-back Actor with a message. Since Actor 0 was created in the filter
chain at the point of suspension it can resume a suspended chain and write a
response. With the Future or similar I need some means for Grizzly to
"wakup" a suspended chain via some not of application initiated event and no
just a OP_xxx NB I/O event. I've seen some languages/libraries where NB I/O
events are peer to application events such as the populating of a Future.
So in I could sync on a couple of channels and a Future or whatever. i.e.
selector.register (ch1, ch2, f1, f2); selector.select would then give me
all ready channels AND ready Futures (those whose value has been set by
another thread).
Bottom line, I wrote too soon and need to do more homework with Grizzly 2.0.
as right now I don't know enough. Given the flexibility of filter chains
and the ability to detach the channel I'm sure pretty much anything is
possible.
Anyway I'm kicking this can down the road for a few days while I wrap up
another section of code and come back to it then.
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
>>
>
>
>