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.
On 7/20/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 7/20/07, yueyu lin <[EMAIL PROTECTED]> wrote: > You are so right. > I found it in the bug database here > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6525190 > and > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933 It seems like the bug has been fixed and the fix will be included in Java 6 update 3, and probably Java 5 update 13. Workaround is described in detail here: http://forum.java.sun.com/thread.jspa?threadID=5135128 It's easy to apply the workaround, but what would be performance impact when applying the workaround? Should we just wait for the next Java release or not? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
-- -- Yueyu Lin
