Hi Yueyu, On 7/20/07, yueyu lin <[EMAIL PROTECTED]> wrote:
In that post, I felt some confused. According Alan's description, it is caused because the sudden connection reset while the underlying file descriptor had no interested events registered for the selector. But in all NIO based applications(at least what I saw), only one thread may handle the register operation. Even in one loop a channel cancel its registers, it will at least hold one interest (OP_READ) or it will recover the (OP_READ) in the next loop(unregister OP_READ to prevent the duplicated events fire). So it will in fact eliminate the problem. Another difference is that in my test, the loop is still hang but the CPU usage in increasing and the status show it's in "i/o wait". The trigger to the problem is the same: the client connection is suddenly closed. But this scenario will recover soon. What's your opinions? I can then post some example codes.
Any example code is appreciated. Please create a JIRA issue so I can run it by myself. I feel like I'd rather not put the workaround into MINA for now though. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
