Hi Igor,
I agree with your observation, comparing blocking vs. non-blocking
modes.
As I understand you make tests with small number of clients, right?
(client_num < worker_threads_num)?
Thanks.
WBR,
Alexey.
>
> 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.
>
> 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
>