Salut,
Igor Minar wrote:
> Hi there,
>
> On Nov 26, 2008, at 1:22 PM, Jeanfrancois Arcand wrote:
>
>>>> Just invoke:
>>>>
>>>> selectorThread.addBannedSelectionKey(..);
>>>>
>>>> > /**
>>>> > * Add a <code>SelectionKey</code> to the banned list of
>>>> SelectionKeys.
>>>> > * A SelectionKey is banned when new registration aren't
>>>> allowed on the
>>>> > * Selector.
>>>> > */
>>>> > public void addBannedSelectionKey(SelectionKey key){
>>>> > bannedKeys.offer(key);
>>>> > }
>>>>
>>>> I'm using this trick for Comet. Which version of GF are you using? I
>>>> suspect the API is there.
>>> Interesting! I must have missed that while reading the Comet code.
>>> So instead of canceling the selectionkey associated with the main
>>> selector, you just mark it as "banned", which causes the selector to
>>> ignore it.
>>
>> Indeed. So the CometSelector has full control over what's happening.
>
> So I played with this today and realized that this api won't work for me.
>
> As I previously mentioned I have two kinds of algorithms blocking and
> non-blocking
> (http://kenai.com/projects/grizzly-sendfile/pages/Algorithms). For in
> order to get the blocking algorithms to work, I need to switch the
> SocketChannel to the blocking mode and that can be done only when that
> channel is not registered with any selector.
I see. This is easy to do with 1.9...let me reminds myself 1.0 :-)
>
> Since addBannedSelectionKey doesn't deregister the channel from the
> selector, it is impossible for me to switch to the blocking mode.
>
> Any idea how to get around this? Is my only option to patch grizzly and
> add my forceKeepAlive() method in order to get this to work?
Hum..I don't like the solution. Let me think of it.
Thanks for the feedback!
-- Jeanfrancois
>
> cheers,
> Igor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>