Special exception for EMFILE / ENFILE when using sockets.

[Norman Maurer]

+1

Also I think it is more consistent with things we already do at the moment. For example there is already a ConnectException, ChannelClosedException etc which is also just an IOException with a “special” errno value.

Just my 2 cents,
Norman
 
> On 7 Dec 2016, at 15:01, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> If you're already having to turn the native error code into (say) an enum or something, it's effectively equivalent to just having different types for every error code.  The difference is just like:
> 
>  try {
>      ...
>  } catch (IOException e) {
>      switch (e.getErrorCode()) {
>          case ECONNRESET: return;
>          case ENFILE: System.out.println("No file descriptors remain"); return;
>          default: throw e; // no idea
>      }
>  }
> 
> versus:
> 
>  try {
>      ...
>  } catch (ConnectionResetException ignored) {
>  } catch (NoFilesRemainingException e) {
>      System.out.println("No file descriptors remain");
>  }
> 
> I like the latter better in probably 95%+ of situations.
> 
> On 12/06/2016 05:14 AM, Langer, Christoph wrote:
>> Hi,
>> 
>> 
>> 
>> I would also support if IOException could be enriched to expose the
>> native error code. However, the user then would need to evaluate this
>> code in a platform specific manner. Maybe there could be some
>> class/interface which would help to translate platform specific error
>> codes to common constants for common error types.
>> 
>> 
>> 
>> Best regards
>> 
>> Christoph
>> 
>> 
>> 
>> *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On Behalf Of
>> *Bernd Eckenfels
>> *Sent:* Montag, 5. Dezember 2016 20:09
>> *To:* net-dev at openjdk.java.net
>> *Subject:* Re: Special exception for EMFILE / ENFILE when using sockets.
>> 
>> 
>> 
>> Hello,
>> 
>> 
>> 
>> I know it is a radical idea, but what about exposing errno value in an
>> IOException.
>> 
>> 
>> 
>> I do think that the new ConnectionRefused subtype is helpful, but for
>> each seldomly occuring error case a dedicated exception is more work
>> than a one time mapping of native errormcodes to fields.
>> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> 
>> 
>> 
>> 
>> On Mon, Dec 5, 2016 at 7:28 PM +0100, "Norman Maurer"
>> <norman.maurer at googlemail.com <mailto:norman.maurer at googlemail.com> <mailto:norman.maurer at googlemail.com <mailto:norman.maurer at googlemail.com>>> wrote:
>> 
>> 
>> 
>> 
>> 
>>    > Am 05.12.2016 um 18:48 schrieb David M. Lloyd :
>> 
>>    >
>> 
>>    >> On 12/05/2016 06:29 AM, Norman Maurer wrote:
>> 
>>    >> Hi all,
>> 
>>    >>
>> 
>>    >> I wonder if it would be possible to add a new public exception time for the situation of an SocketChannel.accept(…) or SocketChannel.open(…)  (and the same for ServerSocket / Socket) failing because of too many open files.
>> 
>>    >> The reason is because especially when acting as a server such an exception may be something you can easily recover from. At there is basically no way to detect if this was the cause of an IOException or not.
>> 
>>    >>
>> 
>>    >> On unix / linux this are the errno values:
>> 
>>    >>
>> 
>>    >> [EMFILE]           The per-process descriptor table is full.
>> 
>>    >> [ENFILE]           The system file table is full.
>> 
>>    >>
>> 
>>    >> For netty we would love to be able to know if this was the case of the problem and if so just stop accepting for a period of time to help the system to recover.
>> 
>>    >>
>> 
>>    >> What others think about this ?
>> 
>>    >
>> 
>>    > I like the idea, but maybe it should be a general IOException since this same error can happen on file open, selector creation (sometimes), pipe creation, etc.
>> 
>>    >
>> 
>>    > --
>> 
>>    > - DML
>> 
>> 
>> 
>>    Sure that would work for me as well :)
>> 
>> 
>> 
>>    Bye,
>> 
>>    Norman
>> 
> 
> -- 
> - DML

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20161207/771529b4/attachment-0001.html>