river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: NPE in Jeri NIO SelectionManager
Date Tue, 09 Aug 2011 18:23:41 GMT
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

Mime
View raw message