> unless there are any objections, I will close 8257080 No objection from me.
> Things have moved on a lot since then, for example I see no reason why > the Java HTTP Client, that uses non-blocking NIO socket channels, could > not do it's own multi-connect thing. Well, I am stuck with Java 8 and if any LDAP server goes down, all java applications will, too. Python, .NET, etc. are not affected. In Java 8 there is no way around it. The next LTS is Java 11 which does ont include the Ldap DNS class you mentioned. As the java.net classes are all not modifiable using a agent or such, this is still a quite unpleasant situation. Which is why I raised this issue in the first place. - Ben Am Di., 22. Dez. 2020 um 18:28 Uhr schrieb Chris Hegarty < chris.hega...@oracle.com>: > I believe that 8170568 [1] better describes the issue being discussed > here. So, unless there are any objections, I will close 8257080 as a > duplicate of 8170568. > > --- > > There was some renewed interest in this area back in mid 2019, when we > touched on it (and several other issues) relating to IPv6 [2] (yes, I > know that this is not an IPv6-only specific issue). > > This is not a new issue, but unfortunately not much progress has been > made in this area (beyond some embedded or mobile platforms doing their > own thing). I remember discussing this with some folks while at the 80th > IETF meeting in Prague, in 2011. Specifically at the time, I prototyped > an implementation of Happy Eyeballs [3] at the java.net.Socket level. If > memory serves me correct, there were some not-so-straightforward > specification issues that would need to worked out, especially relating > to exceptions and failures (I don't have the details to hand). > > Things have moved on a lot since then, for example I see no reason why > the Java HTTP Client, that uses non-blocking NIO socket channels, could > not do it's own multi-connect thing. This is clearly unrelated to > whatever, if anything, is done for java.net.Socket.connect(String,int). > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8170568 > [2] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012371.html > [3] https://tools.ietf.org/html/rfc6555 > > > > On 17 Dec 2020, at 14:39, Chris Hegarty <chris.hega...@oracle.com> > wrote: > > > > Looping in a prior relevant issue in JIRA: > > > > https://bugs.openjdk.java.net/browse/JDK-8170568 - > > Improve address selection for network clients > > > > -Chris. > > > >> On 17 Dec 2020, at 13:45, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > >> > >> Hi Simone, > >> > >> We are investigating introducing a Service Provider interface > >> which would allow an application to replace the default > >> built-in implementation that blocks inside the kernel. > >> > >> There is no plan to introduce any public asynchronous API to perform > >> address resolution at this point. With the advent of Loom and > >> virtual threads I'm not sure there would be much motivation for > >> that anyway. > >> > >> best regards, > >> > >> -- daniel > >> > >> On 16/12/2020 19:59, Simone Bordet wrote: > >>> Hi, > >>> On Wed, Dec 16, 2020 at 5:55 PM Aleks Efimov < > aleksej.efi...@oracle.com> wrote: > >>>> > >>>> Hi Benjamin, > >>>> > >>>> As Alan stated I'm working on adding an SPI [1] which will provide a > >>>> possibility to alter how host names and IP addresses are resolved by > JDK > >>>> platform. > >>>> I believe it would be possible to use this mechanism for addressing > >>>> issue described in JDK-8257080. > >>> Is it hopefully going to be non-blocking? > >> > > > >
