river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Jones (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (RIVER-230) (mux) SelectionManager catch Error block assumes getMessage() returns non-null
Date Thu, 24 Apr 2008 04:27:21 GMT

     [ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Peter Jones resolved RIVER-230.
-------------------------------

    Resolution: Fixed

> (mux) SelectionManager catch Error block assumes getMessage() returns non-null
> ------------------------------------------------------------------------------
>
>                 Key: RIVER-230
>                 URL: https://issues.apache.org/jira/browse/RIVER-230
>             Project: River
>          Issue Type: Bug
>          Components: net_jini_jeri
>    Affects Versions: jtsk_2.0
>            Reporter: Fred Oliver
>            Assignee: Peter Jones
>            Priority: Minor
>             Fix For: AR2
>
>         Attachments: RIVER-230.patch
>
>
> Bugtraq ID [6332547|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332547] 
> com.sun.jini.jeri.internal.runtime.SelectionManager's waitForReadyKey method has the
following catch block in order to work around JDK bug 4458268:
> {noformat}
> 		} catch (Error e) {
> 		    if (e.getMessage().startsWith("POLLNVAL")) {
> 			Thread.yield();
> 			continue;		// work around 4458268
> 		    } else {
> 			throw e;
> 		    }
> {noformat}
> The problem is that Error.getMessage() may return null (in cases other than those that
this code was intended to handle), in which case a NullPointerException will occur.  Such
a NullPointerException has been observed in the output of tests that cause an out-of-memory
condition due to thread creation (in particular, the regression test /vob/qa/jtreg/net/jini/jeri/tcp/outOfThreads/OutOfThreads.java
on Solaris 9):
> {noformat}
> Oct 3, 2005 2:00:52 AM com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop
run
> WARNING: select loop throws
> java.lang.NullPointerException
> 	at com.sun.jini.jeri.internal.runtime.SelectionManager.waitForReadyKey(SelectionManager.java:369)
> 	at com.sun.jini.jeri.internal.runtime.SelectionManager.access$600(SelectionManager.java:80)
> 	at com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop.run(SelectionManager.java:287)
> 	at com.sun.jini.thread.ThreadPool$Worker.run(ThreadPool.java:136)
> 	at java.lang.Thread.run(Thread.java:595)
> (repeated)
> {noformat}
> With the fix for 6304782, the select loop will continue after such an exception, but
the type and stack trace of the original exception does not get logged properly (only the
NPE gets logged).
> -------------
> Two examples of this phenomenon in test failures: (Sun internal URLs removed).
> In the second case, the VM terminated abruptly because of the out-of-memory condition
anyway (not much we can do about that test failure mode?).
> In the first case, the harness timed out the test.  Was that because I/O could not make
progress because of the recurring select loop failures (perhaps also slowed by the loop throttling
after repeated failures)?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message