Archived
This forum has been archived. Please start a new discussion on GitHub.
Ice for java and Runtime.halt()
Stumbled on this gem today, in IceInternal.Selector.select():
I don't want to make a mountain out of a molehill -- I haven't spent any time investigating when java.nio.channels.Selector.select() might throw an IOException, and if it was a common occurence I'm sure this code wouldn't still be here.
But regardless of how rare the situation might be, Ice has no business bringing the entire JVM down.
There's a similar situation in IceInternal.IncomingConnectionFactory.message(), when the listening process exceeds its FD limit.
catch(java.io.IOException ex)
{
//
// Pressing Ctrl-C causes select() to raise an
// IOException, which seems like a JDK bug. We trap
// for that special case here and ignore it.
// Hopefully we're not masking something important!
//
if(Network.interrupted(ex))
{
continue;
}
try
{
String s = "fatal error: selector failed:\n" + ex.getCause().getMessage();
_instance.initializationData().logger.error(s);
}
finally
{
Runtime.getRuntime().halt(1);
}
}
I don't want to make a mountain out of a molehill -- I haven't spent any time investigating when java.nio.channels.Selector.select() might throw an IOException, and if it was a common occurence I'm sure this code wouldn't still be here.
But regardless of how rare the situation might be, Ice has no business bringing the entire JVM down.
There's a similar situation in IceInternal.IncomingConnectionFactory.message(), when the listening process exceeds its FD limit.
0
Comments
-
Similar situation with the C# bindings -- 3 instances of System.Environment.FailFast in ConnectionFactory.cs (when accept() fails for lack of FDs).0