Salut,
Igor Minar wrote:
>
> On Nov 28, 2008, at 7:40 AM, Jeanfrancois Arcand wrote:
>
>> 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.
>
> Any thoughts on this?
>
> I benchmarked my blocking vs nonblocking algorithms [1] and while the
> performance of nonblocking is acceptable, the performance of blocking
> algorithms is superior (10-20%). I totally understand that blocking io
> is ugly and doesn't scale, but I can imagine cases when performance is
> more important than scalability.
>
> Any chance I can get a patch like this accepted in grizzly:
>
> --- DefaultProcessorTask.java.orig 2009-02-18 20:54:29.000000000 -0800
> +++ DefaultProcessorTask.java 2009-02-18 22:43:16.000000000 -0800
> @@ -2228,5 +2228,16 @@
> public boolean getDisableUploadTimeout() {
> return disableUploadTimeout;
> }
> +
> +
> + /**
> + * Ugly patch to prevent non-keep-alive connections from being
> closed when
> + * grizzly-sendfile takes over (when using a blocking algorithm).
> + */
> + public void forceKeepAlive() {
> + keepAlive = true;
> + connectionHeaderValueSet = true;
> + }
> +
> }
>
> I understand that this is a hack because I basically take advantage of
> the fact that keepalive connections are being closed differently than
> non-keepalive connections.
I agree with the method. Just file an issue and I will add it (I will
change the javadoc). An alternative is to expose setKeepAlive but I
think it could be useful to have forceKeepAlive.
Sorry for the delay BTW. Another project suddenly becomes in the
spotlight :-)
A+
-- Jeanfrancois
>
> A proper fix would require to add an api that would allow me to take
> over responsibility for closing a socket channel when I deregister a key
> from the main selector and register it with my custom (grizzly-sendfile)
> selector.
>
> If you don't like this patch then don't worry about it, I plan to use a
> nonblocking algorithm by default starting with grizzly-sendfile 0.3, but
> I thought that it would be nice to have full support for blocking
> algorithms as well.
>
> cheers,
> Igor
>
>
> [1] http://kenai.com/projects/grizzly-sendfile/pages/Algorithms
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>