charlie hunt wrote:
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> charlie hunt wrote:
>>> I'm not sure I agree with the suggested change. ;-)
>>>
>>> With 'nWrite == 0', you will reregister the key when no additional
>>> bytes are written. In other words, as long as more than 0 bytes have
>>> been written you'll continue to write. Only when it says it can't
>>> write any additional bytes will the key be re-registered.
>>>
>>> The main reason I'm disagreeing has to do with the potential cost of
>>> re-registering, parking & unparking a thread being much greater than
>>> spending a few more cpu cycles to keep writing as long as bytes are
>>> successfully written.
>>>
>>> Fwiw, it can take upwards of 50,000+ cpu cycles to go through the
>>> park / unpark.
>>>
>>> I think before blindly putting in the change I'd recommend we do some
>>> performance & scalability tests including some stress tests that have
>>> some really large ByteBuffer writes, (on the order of 100k sized
>>> ByteBuffer).
>>>
>>> Note: My argument is analogous to spinning on a mutex versus
>>> immediately sleeping when trying to obtain a lock. You will most
>>> often acquire the lock much quicker by spinning some number of cycles
>>> versus going to sleep and then being waken.
>>
>> One alternative is to loop over the socketChannel.write(bb) and exit
>> only when nWrite == 0 || !bb.remaining() like we are doing when we use
>> the temporary selector trick. What do you think?
>
> Yes, that may be a better alternative.
>
> I think which choice we make we should do some performance / scalability
> tests before deciding on which is the best approach.
>
> I think the thing(s) we want to avoid are:
> 1.) Force a thread to park & unpark to quickly
> 2.) Minimize the number of interactions with the Selector's
> SelectionKey's, (i.e. enabling / disabling interest ops).
>
> I think if we keep those two principles in mind in this case, I think
> we'll find the most optimal solution.
Agree. But since we don't have the support for benchmarking this right
now (we need to automate faban runs inside Maven 2 so every run can
catch performance regression...I know this is doable :-)) I will go
ahead and commit the fix for now.
Thanks!
-- Jeanfrancois
>
> charlie ...
>
>>
>> -- Jeanfrancois
>>>
>>> charlie ...
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Hi Karsten,
>>>>
>>>> Karsten Ohme wrote:
>>>>> Hi,
>>>>>
>>>>> in TCPConnectorhandler in the read and write methods the key is
>>>>> only reattached if 0 is returned by the read and write method. It
>>>>> would make more sense if the key is reregistered if not all
>>>>> remaining bytes are written.
>>>>>
>>>>> instead of:
>>>>>
>>>>> if (nWrite == 0){
>>>>> key.attach(callbackHandler);
>>>>> selectorHandler.register(key,SelectionKey.OP_WRITE);
>>>>> }
>>>>> better:
>>>>>
>>>>> if (byteBuffer.hasRemaining()){
>>>>> key.attach(callbackHandler);
>>>>> selectorHandler.register(key,SelectionKey.OP_WRITE);
>>>>> }
>>>>
>>>> I agree. Will apply your patch.
>>>>
>>>> Thanks
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Karsten
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>