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.
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
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>