Re: ServerSocket.isBound() continue to return true after close() is called.

; P.S. my bad! I missed this case when working on 6505016 ( in 2007! ) > >> On 11 Apr 2019, at 16:27, Norman Maurer > <mailto:norman.mau...@googlemail.com>> wrote: >> >> Ok thanks… update to the java docs sounds good to me. I was just suprised by >

Re: ServerSocket.isBound() continue to return true after close() is called.

the SocketImpl replacement work that Alan mentioned > recently > and I think we can include this small change probably with one of those. > > Michael. > > On 11/04/2019, 13:40, Norman Maurer wrote: >> >> Hi there, >> >> While working on netty I just notic

ServerSocket.isBound() continue to return true after close() is called.

Hi there, While working on netty I just noticed that a ServerSocket will keep return true when isBound() is called even after it was closed. Is this by design? I was bit surprised by this honestly as after the socket is closed there is no way it will accept any more connections. If this is by

Re: Public API to get the search list that is used on the system

Forgot to ask… is it somehow possible to “subscribe” to an issue and get notified once there are some updates ? Bye Norman > On 27. Sep 2018, at 12:18, Norman Maurer wrote: > > Thanks a lot. > > That would provide exactly what we need in netty. > > Bye > Norman >

Re: Public API to get the search list that is used on the system

Thanks a lot. That would provide exactly what we need in netty. Bye Norman > On 27. Sep 2018, at 12:09, Chris Hegarty wrote: > > Norman, > >> On 26 Sep 2018, at 12:45, Norman Maurer wrote: >> >> BTW I am happy to open an enhancement request for this with mor

Re: Public API to get the search list that is used on the system

BTW I am happy to open an enhancement request for this with more details . Just wanted to check in first here :) Just let me know if I should do or not. Bye Norman > On 26. Sep 2018, at 13:15, Norman Maurer wrote: > > Yeah preferable a method for both but JNDI works for the namese

Re: Public API to get the search list that is used on the system

t up since your specific request is about search domains )? Search > domains are only part of the problem. > > I assume you can retrieve the name servers through the JDNI API, and are > relatively happy with that? > > -Chris. > >> On 26/09/18 11:42, Norman

Re: Public API to get the search list that is used on the system

particular > use-case that you have in mind that requires this? > > -Chris. > > On 26/09/18 10:06, Norman Maurer wrote: >> Hi all, >> I wonder if there is any plan to provide a public domain to receive the >> “search list”. >> At the moment this is

Public API to get the search list that is used on the system

Hi all, I wonder if there is any plan to provide a public domain to receive the “search list”. At the moment this is exposed via an internal API only: sun.net .dns.ResolverConfiguration.searchlist() I know I can use JNDI to get a list of dnsservers but I could not find anythin

Re: [PATCH] SOCK_CLOEXEC for opening sockets

+1 I think this makes a lot of sense > On 10. Jul 2018, at 17:54, Alan Bateman wrote: > > On 10/07/2018 17:40, Martin Buchholz wrote: >> I agree with this approach - it parallels the efforts made with O_CLOEXEC in >> past years. >> >> According to >> https://www.freebsd.org/cgi/man.cgi?query

Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

Hi all, I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) and saw some class-cast-exception with our custom SSLEngine implementation Caused by: java.lang.ClassCastException: class io.netty.handler.ssl.OpenSslEngine cannot be cast to class sun.security.ssl.SSLEngineI

Re: RFR : 8205959 : Do not restart close if errno is EINTR

+1 retry a close on EINTR has most likely not the outcome you expect and may even close a wrong FD if the same FD is reused already (as even if EINTR is returned it may have closed the FD) > Am 02.07.2018 um 10:17 schrieb Baesken, Matthias : > > Hello , there is a similar pattern (attempt to

Re: 8203937: Not possible to read data from socket after write detects connection reset

Sorry for the late response but I was able to verify the fix and all looks good again. Thanks for the quick turn-around, Norman > On 6. Jun 2018, at 11:03, Chris Hegarty wrote: > > >> On 3 Jun 2018, at 12:07, Alan Bateman wrote: >> >> ... >> The following is the webrev to remove the detec

Re: 8203937: Not possible to read data from socket after write detects connection reset

I will test this with Netty as well and report back Bye Norman > Am 03.06.2018 um 13:07 schrieb Alan Bateman : > > This is a follow-up to the "Problem with half-closure related to > connection-reset in Java 11" thread that we've been discussing here over the > last few days. As we discussed, y

Re: Problem with half-closure related to connection-reset in Java 11

> On 1. Jun 2018, at 17:40, Chris Hegarty wrote: > > Norman, > > On 01/06/18 16:33, Norman Maurer wrote: >> ... >> Sure thing (its exactly the same code as in the pr): > > Thank you. I just want to run some tests and verify any > potential changes

Re: Problem with half-closure related to connection-reset in Java 11

Hi Chris, > On 1. Jun 2018, at 17:28, Chris Hegarty wrote: > > Hi Norman, > > On 30/05/18 09:16, Norman Maurer wrote: >> ... >> I added a reproducer which not uses any netty classes to the PR that for now >> ignores test-failures caused by this when running

Re: Problem with half-closure related to connection-reset in Java 11

> On 1. Jun 2018, at 14:50, Alan Bateman wrote: > > > > On 01/06/2018 13:19, Florian Weimer wrote: >> >> But there is a race, even on Linux. If the network is fast enough and you >> get an RST segment from the other end, kernel the receive buffer is >> discarded. > Right although it can

Re: Problem with half-closure related to connection-reset in Java 11

> On 1. Jun 2018, at 14:13, Alan Bateman wrote: > > On 01/06/2018 10:21, Florian Weimer wrote: >> On 05/29/2018 04:26 PM, Norman Maurer wrote: >>> Yes thats what I am saying… I think if a write fails due a connection-reset >>> a read should still be possible

Re: Problem with half-closure related to connection-reset in Java 11

> Am 31.05.2018 um 20:41 schrieb Alan Bateman : > > > >> On 31/05/2018 18:08, Norman Maurer wrote: >> : >>> [1] https://bugs.openjdk.java.net/browse/JDK-8203937 >> Also let me know if you need anything else or want me to test something >> >

Re: Problem with half-closure related to connection-reset in Java 11

> Am 29.05.2018 um 22:49 schrieb Alan Bateman : > >> On 29/05/2018 17:28, Norman Maurer wrote: >> : >> Oh sorry I thought thats the right system to use. I just followed the wiki >> page (I think). > bugs.sun.com or bugreport.java.com is the right place. Th

Re: Problem with half-closure related to connection-reset in Java 11

> On 30. May 2018, at 09:14, Norman Maurer wrote: > > > >> On 29. May 2018, at 22:49, Alan Bateman > <mailto:alan.bate...@oracle.com>> wrote: >> >> On 29/05/2018 17:28, Norman Maurer wrote: >>> : >>> Oh sorry I thought thats th

Re: Problem with half-closure related to connection-reset in Java 11

> On 29. May 2018, at 22:49, Alan Bateman wrote: > > On 29/05/2018 17:28, Norman Maurer wrote: >> : >> Oh sorry I thought thats the right system to use. I just followed the wiki >> page (I think). > bugs.sun.com or bugreport.java.com is the right place. That

Re: Problem with half-closure related to connection-reset in Java 11

> On 29. May 2018, at 18:26, Alan Bateman wrote: > > On 29/05/2018 15:26, Norman Maurer wrote: >> : >> >> >> Yes thats what I am saying… I think if a write fails due a connection-reset >> a read should still be possible until we are told by th

Re: Problem with half-closure related to connection-reset in Java 11

> On 29. May 2018, at 16:19, Alan Bateman wrote: > > On 29/05/2018 14:52, Norman Maurer wrote: >> Hi all, >> >> After trying to run our testsuite in Netty [1] with Java11+ea15 I noticed we >> have one failing test that seems to be related to: >> >

Problem with half-closure related to connection-reset in Java 11

Hi all, After trying to run our testsuite in Netty [1] with Java11+ea15 I noticed we have one failing test that seems to be related to: https://bugs.openjdk.java.net/browse/JDK-8199329 http://hg.openjdk.java.net/jdk/jdk/rev/92cca24c8807

Re: Behaviour of SocketChannelImpl.close() in Java11 (ea+12)

> On 11. May 2018, at 21:34, Alan Bateman wrote: > > (cc'ing nio-dev as as this is asking about SocketChannel). > > On 11/05/2018 19:10, Norman Maurer wrote: >> Hi all, >> >> I recently started to test Netty [1] with Java11 and found that we have two &

Re: Behaviour of SocketChannelImpl.close() in Java11 (ea+12)

Sorry I just noticed this would better be asked on nio.dev. Will ask there. Bye Norman > On 11. May 2018, at 20:10, Norman Maurer wrote: > > Hi all, > > I recently started to test Netty [1] with Java11 and found that we have two > tests that are currently failing due some

Behaviour of SocketChannelImpl.close() in Java11 (ea+12)

Hi all, I recently started to test Netty [1] with Java11 and found that we have two tests that are currently failing due some changes in Java 11 compared to earlier versions. I wanted to get your thoughts on the behaviour changes: 1) SocketChannelImpl.close() will trigger shutdown(…,SHUT_WR) i

Re: JEP 321: HTTP Client (Standard)

Well put David, I couldn’t agree more I would even go this far and say this is not something I would include in the platform itself at all. Bye Norman > Am 04.12.2017 um 19:41 schrieb David Lloyd : > >> On Mon, Dec 4, 2017 at 10:17 AM, wrote: >> New JEP Candidate: http://openjdk.java.n

Re: Expose DNS Servers via public API

Nice! This works :) Norman > On 30. Mar 2017, at 17:27, Alan Bateman wrote: > > On 30/03/2017 15:59, Norman Maurer wrote: > >> Thats why I tried to kick-off the topic :) Thanks for the quick reply btw…. >> So is this list the right place for this discussion ? >&

Re: Expose DNS Servers via public API

> On 30. Mar 2017, at 16:58, Alan Bateman wrote: > > On 30/03/2017 15:36, Norman Maurer wrote: >> Hi there, >> >> I am not sure if this is the correct list for the question but as relate to >> network I will just try. If its the wrong list please tell me whi

Expose DNS Servers via public API

Hi there, I am not sure if this is the correct list for the question but as relate to network I will just try. If its the wrong list please tell me which one would be better fitted. Is there reason why not expose the DNS Servers configured on a system. These are exposed in sun.net.dns.Resolver

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

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 na

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

eption is more work than a one > time mapping of native errormcodes to fields. > > Gruss > Bernd > -- > http://bernd.eckenfels.net <http://bernd.eckenfels.net/> > > > > > On Mon, Dec 5, 2016 at 7:28 PM +0100, "Norman Maurer" > mailto:norman

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

des to fields. > > Gruss > Bernd > -- > http://bernd.eckenfels.net <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 schri

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

> 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 SocketCh

Special exception for EMFILE / ENFILE when using sockets.

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

Re: Introduce IOException subclass for ECONNRESET

example is something that almost always indicates Bad Things). >> >> I also support this proposal. >> >>>> -Original Message- >>>> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of >>>> Chris >>>> Hegarty

Introduce IOException subclass for ECONNRESET

Hi all, I first asked this on nio-dev[0] but was asked to move this over to here: I wonder if it would be possible to add a new IOException sub-class for ECONNRESET. Often you receive these errors if a remote peer closed the connection and you try to read from it while using NIO. This is very o