Hi Alexey,
On Mar 17, 2009, at 6:34 AM, Oleksiy Stashok wrote:
> 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)?
yes, but even with client_num > worker_threads_num blocking io can be
faster if the clients are really fast, but that's not typical, unless
you control clients and can guarantee their speed.
At least that's what I observed during my tests.
/i
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>