On Tuesday, August 09, 2011 Gregg Wonderly wrote: > On 8/9/2011 10:29 AM, Christopher Dolan wrote: >> Has anyone else ever seen this exception? >> >> select loop throws >> java.lang.NullPointerException >> at com.sun.jini.jeri.internal.runtime.SelectionManager.waitForReadyKey(419) >> at com.sun.jini.jeri.internal.runtime.SelectionManager.access$600(80) >> at com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop.run(287) >> at com.sun.jini.thread.ThreadPool$Worker.run(150) >> at java.lang.Thread.run(619) >> > > Looking at this code too Chris, I don't see anything instantly obvious. But, I > do wonder about the use of 'lock' for synchronization given this comment in the > Javadoc: > > "* A selector's key and selected-key sets are not, in general, safe for use > * by multiple concurrent threads. If such a thread might modify one of these > * sets directly then access should be controlled by synchronizing on the set > * itself."
Interesting, I didn't know that about selectors. In this case, I think we may be safe because keys are only added in the constructor and in processRenewQueue(). The latter is only called from the SelectLoop thread, and SelectionManager.concurrency is hard-coded to 1 so there's only one SelectLoop thread. So, the only thread that can attach is the same thread that calls select(). As a short-term solution, I'm going to recommend that my team adds a null check, but I'm not sure what to do if the attachment does turn out to be null. And I'll have to wait and see if this error happens again. Chris
