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