On 06/11/06, Trustin Lee <[EMAIL PROTECTED]> wrote:
> I don't think it would. The problem is that for a given socket, reads > and writes are handled by a single SocketIoProcessor. Reads and writes > cannot happen concurrently *for a given socket*. Reads aand writes are usually memory copy between kernel buffer and Java heap. Is it really more effective to do reads and writes in a separate thread?
I think so, because it means that applications that send and receive concurrently can achieve higher throughput. This would only apply if your hardware including your network was fast enough though.
Also the current SocketIoProcessor is biased for writes, which can > cause problems if a server app has to buffer up responses to be sent > back to a client that is doing a sustained period of writes. Could you please explain why the current SocketIoProcessor is biased for writes? It always stops writing and waits for OP_WRITE whenever the kernel buffer is full (i.e. SocketChannel.write() returns 0).
The problem is that with our hardware we can often keep writing for quite a long time, i.e. the reader "keeps up" therefore it can be a while before we ever see the kernel buffer filling up. In one application which did a lot of writing this caused a problem because it was never reading from the socket and our hearbeating mechanism was effectively not working. The obvious solution is to limit the number of writes done in a given loop but this then leads to throughput reduction. After much messing about we found that using two threads allows reads and writes to run "flat out" as much as possible. RG
