On 12/1/11 2:49 PM, Emmanuel Lécharny wrote:
Forwarded to the ML
Quick note below.
Sent from my iPhone
On Dec 1, 2011, at 7:51 AM, Emmanuel Lécharny<[email protected]>
wrote:
On 12/1/11 1:32 PM, Chad Beaulac wrote:
Hi Emmanuel,
A 1k ByteBuffer will be too small for large data pipes. Consider
using 64k
like you mentioned yesterday.
Yes, this is probably what I'll do.
Draining the channel before returning control to the program can be
problematic. This thread can monopolize the CPU and other necessary
processing could get neglected. The selector will fire again when
there's
more data to read. Suggest removing the loop below and using a 64k
input
buffer.
if we poll the channel with small channels, what will happen is that
we will generate a messageReceived event, which will be processed
immediately. Then we will reset the selector to be put in OP_READ
state, and we will immediately read again the data from the channel.
It's a bit difficult for me to see how it could be less CPU
consuming that reading everything immediately, and then go down the
chain.
Do you have any technical information to back your claim, I would be
very interested to avoid falling in a trap I haven't seen.
It's not a question of CPU consumption. It's managing the reactor
thread fairly.
If you sit in a tight loop like that and one channel is a high data
rate you may not get out in a timely fashion to service change
operations (connect, disconnect, registering for write operations).
Totally makes sense, right !
I can forward a URL to an example later.
Yes, I'd like to read more about this issue.
Anyway, I'll remove the loop, and use a wider buffer.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
