You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Fred Oliver (JIRA)" <ji...@apache.org> on 2007/08/11 00:35:42 UTC
[jira] Created: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
(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
Priority: Minor
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:
} catch (Error e) {
if (e.getMessage().startsWith("POLLNVAL")) {
Thread.yield();
continue; // work around 4458268
} else {
throw e;
}
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):
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)
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.
[jira] Closed: (RIVER-230) (mux) SelectionManager catch Error block
assumes getMessage() returns non-null
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-230.
---------------------------------
> (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.
Re: [jira] Updated: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by Peter Jones <pe...@sun.com>.
On Tue, Apr 08, 2008 at 08:24:10PM +0200, Mark Brouwer wrote:
> Peter Jones (JIRA) wrote:
>> [ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Peter Jones updated RIVER-230:
>> ------------------------------
>>
>> Attachment: RIVER-230.patch
>
> OK.
> --
> Mark
Thanks.
FYI, I haven't committed this or other patches yet because I haven't
been able to get my SVN password set up. (My people.apache.org
password is fine.) Having had no luck with the various instructions I
have found, I followed the last resort instruction of mailing
root@apache.org for a new temporary SVN password, and I am awating a
response.
-- Peter
Re: [jira] Updated: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by Mark Brouwer <ma...@cheiron.org>.
Peter Jones (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Peter Jones updated RIVER-230:
> ------------------------------
>
> Attachment: RIVER-230.patch
OK.
--
Mark
[jira] Updated: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Jones updated RIVER-230:
------------------------------
Attachment: RIVER-230.patch
Attached patch for this issue.
> (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.
[jira] Updated: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by "Fred Oliver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Oliver updated RIVER-230:
------------------------------
Description:
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)?
was:
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:
} catch (Error e) {
if (e.getMessage().startsWith("POLLNVAL")) {
Thread.yield();
continue; // work around 4458268
} else {
throw e;
}
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):
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)
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)?
> (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
> Priority: Minor
>
> 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.
[jira] Updated: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Jones updated RIVER-230:
------------------------------
Fix Version/s: AR2
Assignee: Peter Jones
> (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
>
>
> 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.
[jira] Resolved: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Work started: (RIVER-230) (mux) SelectionManager catch Error
block assumes getMessage() returns non-null
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on RIVER-230 started by Peter Jones.
> (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
>
>
> 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.