> > I have verified that this problem is present in Suns JVM 1.4.1 and > > Suns JVM 1.4.2 > > > > java.lang.NullPointerException > > at > sun.nio.ch.WindowsSelectorImpl$SubSelector.processFDSet(Unknown > > Source) > > at > > > sun.nio.ch.WindowsSelectorImpl$SubSelector.processSelectedKeys(Unknown > > Source) > > at > sun.nio.ch.WindowsSelectorImpl$SubSelector.access$2600(Unknown > > Source) > > at sun.nio.ch.WindowsSelectorImpl.updateSelectedKeys(Unknown > > Source) > > at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source) > > at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source) > > at sun.nio.ch.SelectorImpl.select(Unknown Source) > > at > > > freenet.transport.AbstractSelectorLoop.loop(AbstractSelectorLoop.java: > > 29 > > 5) > > at > > freenet.transport.ReadSelectorLoop.run(ReadSelectorLoop.java:265) > > at java.lang.Thread.run(Unknown Source) > > > > > > Can this workaround be applicable in our case? > > > > http://developer.java.sun.com/developer/bugParade/bugs/4729342.html > > > > >Workaround: > > > > > >I was able to reproduce this bug fairly consistently. It seems to > > >occur when other threads are closing socketChannels. > > >Under the right conditions, it triggers a NullPointerException in > > >the select() call. > > > > > >In my case, the threads were closing the channels when the output > > >buffer was full. (i.e. a call to socketChannel.write > > >(buf) returned zero). Could this be relevant? > > > > > >In any case, to avoid this bug, I added a queue to the > > >selector() thread. Now, when I wanted to close a > > >socketChannel, I add the socketChannel to the queue and > > >then call selector.wakeup(). This wakes up the thread > > >blocked on select() and it now reads off the SocketChannels > > >from the queue and closes them. > > > > > >Having done this, I no longer see the NullPointerException. > > > > > >Hope this helps. BTW, NIO rocks. > > > > > >Regards,... Fred > > Oh for the sake of the code! Closing CAN BLOCK! That is why we already > close() on a separate thread. We REALLY don't want it to have > to run close()s on the SAME thread as the selector. That is > doubleplusevil. Maybe we can catch the NPE?
An effect of the above mentioned NPE is that the node starts consuming 100% CPU until it is shut down (it might be spawning an unlimited number of threads or something). Just catching the NPE and doing a continue; seems to leave the node in a suprisingly working state (at least for local browsing, nothing else tested yet) /N _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
