Ice for java and Runtime.halt()

rowanw

Stumbled on this gem today, in IceInternal.Selector.select():

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.

rowanw

Similar situation with the C# bindings -- 3 instances of System.Environment.FailFast in ConnectionFactory.cs (when accept() fails for lack of FDs).