>>
>>
>> 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.
Right, also you can not "guarantee" the file size, right? :) So in
general for send-file, IMHO, it's more important to be scalable.
WBR,
Alexey.
>
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>