Re: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently

[Dmitry Samersoff]

Felix,

1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for
this test. Could we use different one (e.g. icann.org)

2. This test run JTREG -> Test VM -> Another VM. Could we optimize
process usage?

It might be better to create a jtreg "same vm" process that

   1. launch another process with -Djava.net.preferIPv4Stack=true
   that do A and PRT lookup in one run.

   2. Read results of process above, do PTR lookup with default
   settings and compare results.

-Dmitry


On 2016-12-06 12:06, Felix Yang wrote:
> Hi,
> 
>please review the following patch. It generally coverts codes from
> shell to plain java.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8169115
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/
> 
> Thanks,
> 
> Felix
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

RE: Special exception for EMFILE / ENFILE when using sockets.

[Langer, Christoph]

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-boun...@openjdk.java.net] On Behalf Of Bernd 
Eckenfels
Sent: Montag, 5. Dezember 2016 20:09
To: net-dev@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" 
mailto:norman.mau...@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

Re: Special exception for EMFILE / ENFILE when using sockets.

[Norman Maurer]

While the idea is good I think this will not “fly” because for windows winsock 
is used in the JDK. Winsock does not use the same error constant as bsd sockets 
API (with errno).
In windows we would need to expose “WSAGetLastError()” values and in 
unix/linux/bsd “errno” values. Sure we could try to map for "WSAGetLastError()" 
values to unix/linux/bsd “errno” values but I am not sure this is possible in 
all cases.

That said we do exactly what you suggest edin netty with our own native 
transport that currently only supports linux [1].

[1] 
https://github.com/netty/netty/blob/4.1/transport-native-epoll/src/main/java/io/netty/channel/unix/Errors.java#L73
 

 .



> On 5 Dec 2016, at 20:09, Bernd Eckenfels  wrote:
> 
> 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" 
> mailto:norman.mau...@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

RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently

[Felix Yang]

Hi,

   please review the following patch. It generally coverts codes from 
shell to plain java.


Bug:

https://bugs.openjdk.java.net/browse/JDK-8169115

Webrev:

http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/

Thanks,

Felix