From james at lightbend.com Mon Apr 2 10:18:14 2018 From: james at lightbend.com (James Roper) Date: Mon, 2 Apr 2018 20:18:14 +1000 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: Hi Simone, There are some RS implementations that offer a user facing API that only offers their equivalent of a Publisher to end users, but that is immaterial to RS, since RS is not an end user facing API, but an integration API. End users should not be implementing their own Publisher/Subscriber instances, so it doesn't matter about how difficult they are or aren't to implement. RS compliant implementations should have no problems offering either subscribers or publishers, this is why the RS TCK offers verification for both. I have been involved in the implementation of several RS implementations, including: * Akka Streams * netty-reactive-streams: https://github.com/playframework/netty-reactive-streams/ * A servlet implementation of reactive streams: https://github.com/jroper/reactive-streams-servlet * An iteratees based implemnetation of reactive streams: https://github.com/playframework/play-iteratees Plus, at Lightbend we're also working on an API that is intended to be a proposal for the JDK that offers basic Reactive Streams transformation APIs: https://github.com/lightbend/reactive-streams-utils/ *None* of the above APIs are publisher biased, in fact some of them are even subscriber biased, and they present no problems when implementing the RS APIs. Furthermore, the JDK library proposal also has an implementation using RxJava2, which demonstrates that RxJava, when using Reactive Streams as an integration API, is perfectly capable of exposing and delivering Subscribers as per the spec. I think the problem here is that some libraries have confused the end user API with the integration API. They are not meant to be the same thing. When Lightbend approached the Netflix devs working on RxJava to start the Reactive Streams effort, it was never the intention that we would create a common end user API, it was the intention that we would create an API that would allow our respective streaming libraries to integrate with each other. Reactive Streams is the result. That RxJava has confused these two things is disappointing, but I think it very odd that we would take the constraints of the RxJava and Reactor end user APIs, and force implementations to conform to how they would like all users to use it, even though most other RS implementations don't do that. That makes no sense for an integration API. Regards, James On 31 March 2018 at 00:34, Simone Bordet wrote: > Hi, > > On Wed, Mar 21, 2018 at 9:33 PM, Chris Hegarty > wrote: > > Hi, > > > > This is a request for review for the HTTP Client implementation - JEP > 321. > > It is my understanding, and that of the ReactiveStreams (RS) people I > spoke with, that both the RS API and the higher level API based on RS > (such as those offered by Reactor and RxJava2) are supposed to expose > to users only Publishers. > This may be counterintuitive at beginning: the typical case of > InputStream to read content and OutputStream to write content are both > represented with Publishers in the RS experience. > The reason behind only offering Publishers is that Subscribers are > more difficult to implement by regular developers; Processors even > more so, so it is better that this task is left to library > implementers such as the JDK, Reactor and RxJava2. > > It is therefore a surprise that the the HTTP client uses instead > Subscriber for the response content. > BodyHandler must return a BodySubscriber, which is-a Flow.Subscriber. > > This will force users that need to write non-trivial response content > handling to implement a Subscriber, or most of the times a Processor > (to convert the Subscriber back into a Publisher for consumption by > other more "regular" RS APIs). > It also creates an asymmetry between read and write side, so that for > example it is not possible, without writing a processor, to echo a > response content as the next request content. > Another difficult example is piping the response content to a > WebSocket RS API (that would take a Publisher), and so on for > basically all RS libraries out there. > > I would like to suggest to review this: it is definitely possible to > have BodyHandler refactored in this way: > > public Publisher apply(int statusCode, HttpHeaders responseHeaders, > Publisher responseContent); > > Returning a Publisher that performs transformations on the > responseContent Publisher is the heart of libraries such as Reactor > and RxJava2, so this will be super simple for users of the API. > Utility Publishers that currently discard, convert to string, save to > file, etc. can be equally trivially implemented as they are now in the > JDK. > > With the occasion, I think that the statusCode parameter and the > responseHeaders parameter can be replaced by a single HttpResponse > parameter, which would be better for future maintenance in case other > information needs to be provided. > The simple case that comes to mind is the HTTP version of the > response, which may be different from that of the request and > indicates server capabilities: this is currently not provided in the > BodyHandler.apply() signature. > > So perhaps: > > public Publisher apply(HttpResponse response, Publisher > responseContent); > > This change would also simplify the maintenance since BodySubscriber > will be removed. > > My concern is that driving users of the JDK APIs outside of the > familiar RS APIs offered by Reactor and RxJava2 where only Publishers > are relevant, by forcing them to implement Subscribers and Processors > (heck, I even have an IntelliJ warning telling me that I should not do > that!), will cause confusion and be potential source of bugs - we all > know non-blocking/async programming is hard. > > Thanks ! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > -- *James Roper* *Senior Octonaut* Lightbend ? Build reactive apps! Twitter: @jroper -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Apr 2 10:39:03 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 2 Apr 2018 11:39:03 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: Hi Simone, Thank you for your reply. I have inserted inline my replies to specific assertions and comments, but please continue to read on past these as there two concrete proposals further down that address your concerns, as I understand them. > On 30 Mar 2018, at 14:34, Simone Bordet > wrote: > > ... > It is my understanding, and that of the ReactiveStreams (RS) people I > spoke with, that both the RS API and the higher level API based on RS > (such as those offered by Reactor and RxJava2) are supposed to expose > to users only Publishers. I can find no material supporting this assertion on reactive-streams.org , or anywhere else for that matter. This is not something that I have, or any member of the HTTP Client team has, ever come across. We have had review comments and feedback, on this list, from folk in the Reactive Streams community ( that greatly improved interoperability ), and this has never come up. Without supporting material, I cannot accept this assertion. Publisher and Subscriber are low level building blocks that can be used by different Reactive Streams (RS) implementations. They were added to Java SE 9 to provide interoperability between various RS implementations. The HTTP Client API, being proposed for inclusion in Java SE 11, can only directly reference other Java SE types, so uses Publisher and Subscriber directly. The HTTP Client API provides out-of-the-box Publisher and Subscriber implementations for various common operations. Beyond that, custom implementations can be used, or more likely Publishers and Subscribers from RS implementations. Interoperability with these RS implementations is of utmost importance. At the end of a Flow, there must always be a Subscriber. Without it there is no demand. Therefore, all RS APIs must provide Subscribers of some sort or other. > This may be counterintuitive at beginning: the typical case of > InputStream to read content and OutputStream to write content are both > represented with Publishers in the RS experience. > The reason behind only offering Publishers is that Subscribers are > more difficult to implement by regular developers; I am surprised by this assertion. Our experience writing Publishers and Subscribers has shown that the most difficult piece of code to write, in a scalable thread-safe manner, is the Subscription::request. Subscriptions are created and returned by a Publisher and usually have an intimate relationship with their Publisher. I consider them part of the Publishing-side. If a Publisher is not creating its own Subscription, but instead returning a Subscription from an upstream Publisher, in a chain, then some work can be avoided, but this is not always the case. I believe that this could be the scenario that you are referring to, but it is not always the case. The HTTP Client deliberately does not expose its Publisher of response body data. It instead subscribes the given Subscriber, on behalf of the invoking code. There can, and must, be a single Subscriber. This is a simple and safe model, expected to be more readily understood by an average Java developer ( than exposing a Publisher ). If Publishers are better for interoperability with some RS implementations, then this could be addressed by a small addition to the API, as proposed later in this mail (see below). > Processors even > more so, so it is better that this task is left to library > implementers such as the JDK, Reactor and RxJava2. Again, similar to Publisher, these are highly context sensitive. For some common "pass-through" scenarios then they can be relatively straight forward, but not so when processing is required. I agree, I think the average Java developer should not be expected to write these, for common scenarios. > It is therefore a surprise that the the HTTP client uses instead > Subscriber for the response content. > BodyHandler must return a BodySubscriber, which is-a Flow.Subscriber. The HTTP Client has had this design for a couple of years now, and the use of Subscriber ( of response body data ) has not surprised anyone, to my knowledge. Again, folk in the Reactive Streams community are aware of this API. > This will force users that need to write non-trivial response content > handling to implement a Subscriber, or most of the times a Processor > (to convert the Subscriber back into a Publisher for consumption by > other more "regular" RS APIs). In many cases a simple single Subscriber ( sink ) will be a reasonable choice. The HTTP Client provides a number of combinators and adapters that demonstrate the composability of Subscribers. For interoperability with other RS implementations, where the Flow adaptation is being done through Publishers, I would expect folk to use something like RxJava2's `io.reactivex.processors.PublishProcessor`. In fact, Daniel just wrote something similar in a recent test [1], a handler that makes the response body available through a Publisher, `BodyHandler>>`. It is a not a general purpose Processor, but a Subscriber that makes its data available through a Publisher. > It also creates an asymmetry between read and write side, so that for > example it is not possible, without writing a processor, to echo a > response content as the next request content. Sorry, the read-side and write-side are just different ( but use the appropriate consumer and producer API from RS ). I don't see this as an asymmetry. One can use the aforementioned `PublishProcessor` if echo is required. > Another difficult example is piping the response content to a > WebSocket RS API (that would take a Publisher), and so on for > basically all RS libraries out there. Already answered above. > I would like to suggest to review this: it is definitely possible to > have BodyHandler refactored in this way: > > public Publisher apply(int statusCode, HttpHeaders responseHeaders, > Publisher responseContent); > > Returning a Publisher that performs transformations on the > responseContent Publisher is the heart of libraries such as Reactor > and RxJava2, so this will be super simple for users of the API. If one is using a RS API then maybe this would be easier, but not so for other cases. I content that writing Publisher is not as easy as a Subscriber, and we already know that a Subscriber is required. Such an API would require developers, not using an RS API, to have to write a Publisher and a Subscriber. > Utility Publishers that currently discard, convert to string, save to > file, etc. can be equally trivially implemented as they are now in the > JDK. Yes, probably, but doesn't provide anything more than we already have. I don't believe that this is a simplification or improves interoperability in any way. The one area that I do see some room for improvement is the possibility of providing a Publishing handler out of the box, so one does not need to reach beyond Java SE for such echo use-cases. Daniel already has this code in the repository as a test [1], so it would not take much work to provide an API similar to: BodyHandlers { .. public static BodyHandler>> ofPublisher() {...} .. } Does this satisfy your concern? --- > With the occasion, I think that the statusCode parameter and the > responseHeaders parameter can be replaced by a single HttpResponse > parameter, which would be better for future maintenance in case other > information needs to be provided. We have considered similar ( a data carrier rather than explicit parameters ) a number of times, but discounted it, since we found no use-cases for additional information, and none have come to light. Is a carrier, its instantiation per response, API footprint, warranted? To date, we have not found it a limiting factor, but I agree that it would be somewhat easier to evolve the API with such a carrier. > The simple case that comes to mind is the HTTP version of the > response, which may be different from that of the request and > indicates server capabilities: this is currently not provided in the > BodyHandler.apply() signature. What use case have you in mind for this? > So perhaps: > > public Publisher apply(HttpResponse response, Publisher > responseContent); > > This change would also simplify the maintenance since BodySubscriber > will be removed. Your sketch API design throws out `BodySubscriber` that is at the core of the whole API, it is responsible for conversation of response body bytes to the higher-level object, and control flow through its `CompletionStage` ( I don't see how you address control flow in your sketch ). What you are suggesting is a significant change, not prototyped, not incubated, not easier to use, and from what I can see brings no improvements. You are proposing an alternative design based on your assertions above ( some of which I disagree with ). I accept that a carrier would be a more friendly for possible evolution, maybe: BodyHandlerInfo { int statusCode() {... } HttpHeaders responseHeaders { ... } } Does this satisfy your concern? --- > My concern is that driving users of the JDK APIs outside of the > familiar RS APIs offered by Reactor and RxJava2 where only Publishers > are relevant, by forcing them to implement Subscribers and Processors > (heck, I even have an IntelliJ warning telling me that I should not do > that!), will cause confusion and be potential source of bugs - we all > know non-blocking/async programming is hard. No one is forcing anyone outside of RS APIs. They already support Subscribers and Publishing Processors. They already have what is needed. I have made two concrete proposals in this email that attempt to address concerned that you have raised. Both represent improvements while staying within the current design. Do these satisfy your concerns? -Chris. [1] http://hg.openjdk.java.net/jdk/sandbox/file/c59f684f1eda/test/jdk/java/net/httpclient/ResponsePublisher.java -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Mon Apr 2 12:09:34 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 2 Apr 2018 14:09:34 +0200 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: James, perhaps I was not clear enough. The JDK will offer an API based on RS, so that's a user-facing API. Given that, the question is whether the surface of exposition to users when they want to use the JDK HttpClient API should be limited to Publishers, or expanded to Publishers, Subscribers and Processors. My suggestion was to limit it to Publishers only. Forcing users to implement Subscribers or Processors (because that's what the API requires, despite having a few utilities that cover the common cases) is way more difficult for users than just passing around a Publisher. It is by exposing Publishers only that you get rid of the need for users to implement any of the RS interfaces to interoperate with other libraries. I'm not sure I buy your opinion on the RxJava2 and Reactor libraries (peace! :) Both have plenty APIs to create a Flowable/Flux from Publishers, and almost none to handle Subscribers: Publishers are exposed, Subscribers hidden. I don't see any confusion. Thanks ! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Apr 2 13:08:36 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 2 Apr 2018 15:08:36 +0200 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: Hi, On Mon, Apr 2, 2018 at 12:39 PM, Chris Hegarty wrote: > I can find no material supporting this assertion on reactive-streams.org, > or anywhere else for that matter. This is not something that I have, or > any member of the HTTP Client team has, ever come across. We have had > review comments and feedback, on this list, from folk in the Reactive > Streams community ( that greatly improved interoperability ), and this > has never come up. Without supporting material, I cannot accept this > assertion. Fair enough. I had my impression by using/designing APIs around RS, but I guess it's a cat that can be skinned in various ways. > The HTTP Client deliberately does not expose its Publisher of response > body data. It instead subscribes the given Subscriber, on behalf of the > invoking code. There can, and must, be a single Subscriber. This is a > simple and safe model, expected to be more readily understood by an > average Java developer ( than exposing a Publisher ). If Publishers are > better for interoperability with some RS implementations, then this > could be addressed by a small addition to the API, as proposed later in > this mail (see below). I guess this is the guts of what I wanted to discuss. I would have preferred to see the Publisher exposed, rather than having user code to pass a Subscriber to the implementation. Again, I guess it's matter of personal experience, and again the current way works, so I can't bring strong arguments against it. > For interoperability > with other RS implementations, where the Flow adaptation is being done > through Publishers, I would expect folk to use something like RxJava2's > `io.reactivex.processors.PublishProcessor`. In fact, Daniel just wrote > something similar in a recent test [1], a handler that makes the > response body available through a Publisher, > `BodyHandler>>`. It is a not a general > purpose Processor, but a Subscriber that makes its data available > through a Publisher. Sure. Again, my point was more along the lines that providing a Publisher was more immediately familiar to users of other libraries. I guess all those libraries have a way to convert a Subscriber to a Publisher, so no big deal - just feels a little more complicated to me. > so it would not take much work to provide an API similar to: > > BodyHandlers { > .. > public static BodyHandler>> ofPublisher() {...} > .. > } > > Does this satisfy your concern? Yes, a way to convert the Subscriber to a Publisher via a utility Processor provided by the JDK that users won't need to implement. > I accept that a carrier would be a more friendly for possible evolution, > maybe: > > BodyHandlerInfo { > int statusCode() {... } > HttpHeaders responseHeaders { ... } > } > > Does this satisfy your concern? Yes. This class could already hold the HTTP version, and possibly in future other information (e.g. whether the response has a body or not). Thanks ! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From viktor.klang at gmail.com Tue Apr 3 07:49:31 2018 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 3 Apr 2018 09:49:31 +0200 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: Hi Simone! :) I think James conveyed basically everything I had in mind to respond, but I felt compelled to address the following: >Forcing users to implement Subscribers or Processors (because that's what the API requires, despite having a few utilities that cover the common cases) is way more difficult for users than just passing around a Publisher. Simply because an API has an interface type as an parameter or a return value does not (in my mind) in any way imply that end-users (think: application developers) are required, encouraged, forced, or otherwise, to create their own implementations of said interface types to be able to use it. What is pretty awesome though is if someone has a need for functionality not provided elsewhere, is that Reactive Streams has a formal specification and a?free and readily available?TCK to guide implementors to implement them correctly. On Mon, Apr 2, 2018 at 2:09 PM, Simone Bordet wrote: > James, > > perhaps I was not clear enough. > > The JDK will offer an API based on RS, so that's a user-facing API. > > Given that, the question is whether the surface of exposition to users > when they want to use the JDK HttpClient API should be limited to > Publishers, or expanded to Publishers, Subscribers and Processors. > My suggestion was to limit it to Publishers only. > Forcing users to implement Subscribers or Processors (because that's > what the API requires, despite having a few utilities that cover the > common cases) is way more difficult for users than just passing around > a Publisher. > > It is by exposing Publishers only that you get rid of the need for > users to implement any of the RS interfaces to interoperate with other > libraries. > > I'm not sure I buy your opinion on the RxJava2 and Reactor libraries > (peace! :) > Both have plenty APIs to create a Flowable/Flux from Publishers, and > almost none to handle Subscribers: Publishers are exposed, Subscribers > hidden. > I don't see any confusion. > > Thanks ! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > -- Cheers, ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdeleuze at pivotal.io Thu Apr 5 10:07:21 2018 From: sdeleuze at pivotal.io (Sebastien Deleuze) Date: Thu, 5 Apr 2018 12:07:21 +0200 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 Message-ID: Hi, I am currently implementing a draft support for JDK new HTTP client in Spring Framework 5 [1] (using JDK 10 for now) in order to be able to leverage it as a WebClient [2] engine. Our integration tests all pass with regular HTTP/1.1 webservices (we have not tested the HTTP/2 support yet), but not with streaming APIs. Based on my current understanding, it seems the CompletableFuture returned by HttpClient#sendAsync completes only when all the data of the response body is available, not asap the status code + headers are available like with Jetty or Reactor Netty clients (which prevents to consume infinite streams via Reactive Streams API). Is consuming streaming HTTP/1.1 endpoints (like JSON streaming or SSE) supported by current implementation? Regards, S?bastien Deleuze [1] https://github.com/sdeleuze/jdk-http-webclient/ [2] https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-client -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Thu Apr 5 13:56:51 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 05 Apr 2018 14:56:51 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: Message-ID: <5AC62B23.6000204@oracle.com> Sebastien, The answer depends on the particular HttpResponse.BodySubscriber/Handler implementation supplied to the sendAsync() call. Some of the simpler ones which return aggregate/completed objects like String, or byte[] do not appear to stream and the response body is not returned until after all data has been read. But, BodySubscribers and handlers can be designed to return the body reading object any time after the response headers have been received. One example is the BodySubscriber which is another standard implementation we provide. Obviously, in that case, the InputStream does not represent the completely read body, but is just an object used to read the body. Note, the only difference between those two types of body subscriber is when the object returned from HttpResponse.body() becomes visible. In both cases, the data is streamed to the subscriber object as it is received and according to the normal flow control rules of the j.u.concurrent.Flow API. Hope this helps, Michael. On 05/04/2018, 11:07, Sebastien Deleuze wrote: > Hi, > > I am currently implementing a draft support for JDK new HTTP client in > Spring Framework 5 [1] (using JDK 10 for now) in order to be able to > leverage it as a WebClient [2] engine. > > Our integration tests all pass with regular HTTP/1.1 webservices (we > have not tested the HTTP/2 support yet), but not with streaming APIs. > Based on my current understanding, it seems > the CompletableFuture returned by HttpClient#sendAsync > completes only when all the data of the response body is available, > not asap the status code + headers are available like with Jetty or > Reactor Netty clients (which prevents to consume infinite streams via > Reactive Streams API). > > Is consuming streaming HTTP/1.1 endpoints (like JSON streaming or SSE) > supported by current implementation? > > Regards, > S?bastien Deleuze > > [1] https://github.com/sdeleuze/jdk-http-webclient/ > [2] > https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-client -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Apr 5 16:12:08 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Apr 2018 17:12:08 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: Message-ID: <99D812C6-E0FE-444F-99DD-DC38C64E61B4@oracle.com> Hi Sebastien, > On 5 Apr 2018, at 11:07, Sebastien Deleuze wrote: > > Hi, > > I am currently implementing a draft support for JDK new HTTP client in Spring Framework 5 [1] (using JDK 10 for now) in order to be able to leverage it as a WebClient [2] engine. Great that you are trying this out. > Our integration tests all pass with regular HTTP/1.1 web services Good to hear this. > (we have not tested the HTTP/2 support yet), but not with streaming APIs. Reactive streams APIs consist of both Publishers and Subscribers, but in your specific case you appear to most interested in Publishers. I'll assume "streaming APIs? here means "RS Publishers", since the HTTP Client quite obvious interoperates with Subscribers. > Based on my current understanding, it seems the CompletableFuture returned by HttpClient#sendAsync completes only when all the data of the response body is available, not asap the status code + headers are available like with Jetty or Reactor Netty clients (which prevents to consume infinite streams via Reactive Streams API). As Michael has already said, it can operate either way depending on the actual higher-level Java type that the body is being converted to. In fact, you can even write your own BodyHandler that returns a Subscriber with an already complete body CF. So there is no issue working with infinite streams via RS, if that is what you want. I believe what you are actually seeking is a `BodyHandler>>`, that makes its HttpResponse available once the headers have been received. This has come up just recently, in this email thread [1]. A JIRA issue has been filed to track the addition of such a BodyHandler [2]. In the interim, until the new handler can been added, it should be possible to either write your own ( Daniel has similar, `static class PublishingBodySubscriber implements BodySubscriber>>`, in a test [3] ). Or if your library, or reactor, provides functionality similar to `io.reactivex.processors.PublishProcessor`, then you can use it as the BodyHandler type and write a delegating BodySubscriber that completes its body CF immediately with an instance of that processor. > Is consuming streaming HTTP/1.1 endpoints (like JSON streaming or SSE) supported by current implementation? Yes, but of course not out of the box, you need to hook up to a JSON Subscriber, etc. -Chris. [1] http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011314.html [2] https://bugs.openjdk.java.net/browse/JDK-8201186 [3] http://hg.openjdk.java.net/jdk/sandbox/file/c59f684f1eda/test/jdk/java/net/httpclient/ResponsePublisher.java From sdeleuze at pivotal.io Thu Apr 5 18:09:18 2018 From: sdeleuze at pivotal.io (Sebastien Deleuze) Date: Thu, 5 Apr 2018 20:09:18 +0200 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: <99D812C6-E0FE-444F-99DD-DC38C64E61B4@oracle.com> References: <99D812C6-E0FE-444F-99DD-DC38C64E61B4@oracle.com> Message-ID: Michael, Chris, Thanks for your feedback, indeed with PublishingBodySubscriber, it works also for streaming use cases and it provides the behavior I was trying to achieve. So +1 for inclusion of JDK-8201186 in JDK 11. On Thu, Apr 5, 2018 at 6:12 PM, Chris Hegarty wrote: > Hi Sebastien, > > > On 5 Apr 2018, at 11:07, Sebastien Deleuze wrote: > > > > Hi, > > > > I am currently implementing a draft support for JDK new HTTP client in > Spring Framework 5 [1] (using JDK 10 for now) in order to be able to > leverage it as a WebClient [2] engine. > > Great that you are trying this out. > > > Our integration tests all pass with regular HTTP/1.1 web services > > Good to hear this. > > > (we have not tested the HTTP/2 support yet), but not with streaming APIs. > > Reactive streams APIs consist of both Publishers and Subscribers, but > in your specific case you appear to most interested in Publishers. I'll > assume "streaming APIs? here means "RS Publishers", since the HTTP > Client quite obvious interoperates with Subscribers. > > > Based on my current understanding, it seems the CompletableFuture > returned by HttpClient#sendAsync completes only when all the data of the > response body is available, not asap the status code + headers are > available like with Jetty or Reactor Netty clients (which prevents to > consume infinite streams via Reactive Streams API). > > As Michael has already said, it can operate either way depending on the > actual higher-level Java type that the body is being converted to. In > fact, you can even write your own BodyHandler that returns a Subscriber > with an already complete body CF. So there is no issue working with > infinite streams via RS, if that is what you want. > > I believe what you are actually seeking is a > `BodyHandler>>`, that makes its HttpResponse > available once the headers have been received. This has come up just > recently, in this email thread [1]. A JIRA issue has been filed to track > the addition of such a BodyHandler [2]. > > In the interim, until the new handler can been added, it should be > possible to either write your own ( Daniel has similar, > `static class PublishingBodySubscriber implements > BodySubscriber>>`, in a test [3] ). Or > if your library, or reactor, provides functionality similar to > `io.reactivex.processors.PublishProcessor`, then you can use it as the > BodyHandler type and write a delegating BodySubscriber that > completes its body CF immediately with an instance of that processor. > > > Is consuming streaming HTTP/1.1 endpoints (like JSON streaming or SSE) > supported by current implementation? > > > Yes, but of course not out of the box, you need to hook up to a JSON > Subscriber, etc. > > -Chris. > > [1] http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011314.html > [2] https://bugs.openjdk.java.net/browse/JDK-8201186 > [3] http://hg.openjdk.java.net/jdk/sandbox/file/c59f684f1eda/ > test/jdk/java/net/httpclient/ResponsePublisher.java > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sshamaia at in.ibm.com Mon Apr 9 09:58:18 2018 From: sshamaia at in.ibm.com (Srividya Shamaiah) Date: Mon, 9 Apr 2018 15:28:18 +0530 Subject: 8169865 : Changes not ported to IPv4 Message-ID: Hi , In method Java_java_net_Inet6AddressImpl_getLocalHostName , file src/solaris/native/java/net/Inet6AddressImpl.c , there were changes that was added due to 8169865: Downport minor fixes in java.net native code from JDK 9 to JDK 8 which removed the additional work for non Solaris platforms of doing a reverse lookup to get the hostname. Is there any specific reason as to why the same change is not added to method Java_java_net_Inet4AddressImpl_getLocalHostName, file src/solaris/native/java/net/Inet4AddressImpl.c . For IPv4 we still continue to resolve hostname through nameservice for all UNIX platforms while for IPv6 we do this only for Solaris platforms. Thanks, Srividya S -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Apr 9 16:11:21 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 Apr 2018 17:11:21 +0100 Subject: 8169865 : Changes not ported to IPv4 In-Reply-To: References: Message-ID: Hi Srividya, On 09/04/18 10:58, Srividya Shamaiah wrote: > Hi , > In method Java_java_net_Inet6AddressImpl_getLocalHostName , file > *src/solaris/native/java/net/Inet6AddressImpl.c *, there were changes > that was added due to *8169865: Downport minor fixes in java.net native > code from JDK 9 to JDK 8 *which removed the additional work for non > Solaris platforms of doing a reverse lookup to get the hostname. Is > there any specific reason as to why the same change is not added to > method Java_java_net_Inet4AddressImpl_getLocalHostName, file > *src/solaris/native/java/net/Inet4AddressImpl.c *. For IPv4 we still > continue to resolve hostname through nameservice for all UNIX platforms > while for IPv6 we do this only for Solaris platforms. The changes for 8169865, in this area, were mainly motivated by clean up, rather than function. I agree that there is an inconsistency between the IPv4 and IPv6 lookup implementations. This inconsistency has been for many many years. Are you seeing any specific issues relating to this? -Chris. From michael.x.mcmahon at oracle.com Mon Apr 9 18:01:55 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Apr 2018 19:01:55 +0100 Subject: RFR: 8196775: java/net/Socket/asyncClose/Race.java failed intermittently on Windows with ConnectException: Connection refused Message-ID: <5ACBAA93.7060407@oracle.com> Can I get the following small test change reviewed please. The test is occasionally failing with a ConnectException that is most likely caused by the backlog limit being reached. So, I have set a higher backlog and also am ignoring the specifi ConnectionException. http://cr.openjdk.java.net/~michaelm/8196775/webrev.1/ Thanks, Michael From sshamaia at in.ibm.com Tue Apr 10 11:34:53 2018 From: sshamaia at in.ibm.com (Srividya Shamaiah) Date: Tue, 10 Apr 2018 17:04:53 +0530 Subject: 8169865 : Changes not ported to IPv4 In-Reply-To: References: Message-ID: Hi Chris, One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Thanks, Srividya S From: Chris Hegarty To: Srividya Shamaiah , net-dev at openjdk.java.net Date: 09/04/2018 09:41 PM Subject: Re: 8169865 : Changes not ported to IPv4 Hi Srividya, On 09/04/18 10:58, Srividya Shamaiah wrote: > Hi , > In method Java_java_net_Inet6AddressImpl_getLocalHostName , file > *src/solaris/native/java/net/Inet6AddressImpl.c *, there were changes > that was added due to *8169865: Downport minor fixes in java.net native > code from JDK 9 to JDK 8 *which removed the additional work for non > Solaris platforms of doing a reverse lookup to get the hostname. Is > there any specific reason as to why the same change is not added to > method Java_java_net_Inet4AddressImpl_getLocalHostName, file > *src/solaris/native/java/net/Inet4AddressImpl.c *. For IPv4 we still > continue to resolve hostname through nameservice for all UNIX platforms > while for IPv6 we do this only for Solaris platforms. The changes for 8169865, in this area, were mainly motivated by clean up, rather than function. I agree that there is an inconsistency between the IPv4 and IPv6 lookup implementations. This inconsistency has been for many many years. Are you seeing any specific issues relating to this? -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From joelpelaez at gmail.com Mon Apr 9 22:36:49 2018 From: joelpelaez at gmail.com (=?UTF-8?Q?Joel_Pel=c3=a1ez_Jorge?=) Date: Mon, 9 Apr 2018 17:36:49 -0500 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address Message-ID: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> Hi, I am new in the OpenJDK Community and I contribute with a fix for the bug 8200719 related to networking in macOS system. I wrote a minimal patch that only set the scope id when the address is link-local or multicast. This change avoid send IPv6 packets on a wrong interface. Bug: https://bugs.openjdk.java.net/browse/JDK-8200719 Patch: diff -r f088ec60bed5 src/java.base/unix/native/libnet/net_util_md.c --- a/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 10:39:29 2018 -0700 +++ b/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 16:50:18 2018 -0500 @@ -89,7 +89,8 @@ } int defaultIndex; struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)him; - if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0)) { + if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0) && + (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr) || IN6_IS_ADDR_MULTICAST(&sin6->sin6_addr))) { defaultIndex = (*env)->GetStaticIntField(env, ni_class, ni_defaultIndexID); sin6->sin6_scope_id = defaultIndex; Thanks, Joel From daniel.fuchs at oracle.com Tue Apr 10 14:07:19 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 10 Apr 2018 15:07:19 +0100 Subject: RFR: 8196775: java/net/Socket/asyncClose/Race.java failed intermittently on Windows with ConnectException: Connection refused In-Reply-To: <5ACBAA93.7060407@oracle.com> References: <5ACBAA93.7060407@oracle.com> Message-ID: <7d339808-896c-5c9b-196c-b3f3ce761de9@oracle.com> Hi Michael, This looks reasonable to me. best, -- daniel On 09/04/2018 19:01, Michael McMahon wrote: > Can I get the following small test change reviewed please. > > The test is occasionally failing with a ConnectException that is most > likely caused by > the backlog limit being reached. So, I have set a higher backlog and > also am ignoring the specifi > ConnectionException. > > http://cr.openjdk.java.net/~michaelm/8196775/webrev.1/ > > Thanks, > > Michael From chris.hegarty at oracle.com Tue Apr 10 15:20:57 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 Apr 2018 16:20:57 +0100 Subject: 8169865 : Changes not ported to IPv4 In-Reply-To: References: Message-ID: > On 10 Apr 2018, at 12:34, Srividya Shamaiah wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://bugs.openjdk.java.net/browse/JDK-8201369 -Chris. From sshamaia at in.ibm.com Wed Apr 11 07:19:14 2018 From: sshamaia at in.ibm.com (Srividya Shamaiah) Date: Wed, 11 Apr 2018 12:49:14 +0530 Subject: 8169865 : Changes not ported to IPv4 In-Reply-To: References: Message-ID: Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S From: Chris Hegarty To: Srividya Shamaiah Cc: OpenJDK Network Dev list Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 > On 10 Apr 2018, at 12:34, Srividya Shamaiah wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From christoph.langer at sap.com Wed Apr 11 09:21:45 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Apr 2018 09:21:45 +0000 Subject: 8169865 : Changes not ported to IPv4 In-Reply-To: References: Message-ID: Hi Srividya, I would also welcome this fix. Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Srividya Shamaiah Sent: Mittwoch, 11. April 2018 09:19 To: Chris Hegarty Cc: OpenJDK Network Dev list Subject: Re: 8169865 : Changes not ported to IPv4 Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S [Inactive hide details for Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > From: Chris Hegarty > To: Srividya Shamaiah > Cc: OpenJDK Network Dev list > Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 ________________________________ > On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: image001.gif URL: From christoph.langer at sap.com Wed Apr 11 09:42:21 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Apr 2018 09:42:21 +0000 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> Message-ID: <3213e968c9794f579d87cd3a33deec46@sap.com> Hi Joel, your fix sounds reasonable. In fact, I'm not even sure if the sin6_scope_id should be set for multicast. Maybe it should be done only for link local addresses. Additionally, I guess the selection of the default interface (for IPv6) should be improved because I still can imagine a scenario where the first interface only has IPv4 but you want to do an IPv6 link local connect where you need a scope. Do you have signed an OCA as per [1], section "0. Become a Contributor"? Then I can help you with sponsoring this... Best regards Christoph [1] http://openjdk.java.net/contribute/ > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > Joel Pel?ez Jorge > Sent: Dienstag, 10. April 2018 00:37 > To: net-dev at openjdk.java.net > Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active > network interface without IPv6 address > > Hi, > > I am new in the OpenJDK Community and I contribute with a fix for the bug > 8200719 related to networking in macOS system. > > I wrote a minimal patch that only set the scope id when the address is link- > local or multicast. This change avoid send IPv6 packets on a wrong interface. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200719 > > Patch: > > diff -r f088ec60bed5 src/java.base/unix/native/libnet/net_util_md.c > --- a/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 10:39:29 > 2018 -0700 > +++ b/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 16:50:18 > 2018 -0500 > @@ -89,7 +89,8 @@ > } > int defaultIndex; > struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)him; > - if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0)) { > + if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0) && > + (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr) || > IN6_IS_ADDR_MULTICAST(&sin6->sin6_addr))) { > defaultIndex = (*env)->GetStaticIntField(env, ni_class, > ni_defaultIndexID); > sin6->sin6_scope_id = defaultIndex; > > > Thanks, > Joel From sshamaia at in.ibm.com Wed Apr 11 10:05:38 2018 From: sshamaia at in.ibm.com (Srividya Shamaiah) Date: Wed, 11 Apr 2018 15:35:38 +0530 Subject: 8169865 : Changes not ported to IPv4 In-Reply-To: References: Message-ID: Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, Srividya S From: "Langer, Christoph" To: Srividya Shamaiah , Chris Hegarty Cc: OpenJDK Network Dev list Date: 11/04/2018 02:51 PM Subject: RE: 8169865 : Changes not ported to IPv4 Hi Srividya, I would also welcome this fix. Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Srividya Shamaiah Sent: Mittwoch, 11. April 2018 09:19 To: Chris Hegarty Cc: OpenJDK Network Dev list Subject: Re: 8169865 : Changes not ported to IPv4 Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S Inactive hide details for Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah On 10 Apr 2018, at 12:34, Srividya Shamaiah < sshamaia at in.ibm.com> wrote: > From: Chris Hegarty To: Srividya Shamaiah Cc: OpenJDK Network Dev list Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 > On 10 Apr 2018, at 12:34, Srividya Shamaiah wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From joelpelaez at gmail.com Wed Apr 11 10:53:49 2018 From: joelpelaez at gmail.com (=?UTF-8?Q?Joel_Pel=c3=a1ez_Jorge?=) Date: Wed, 11 Apr 2018 05:53:49 -0500 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <3213e968c9794f579d87cd3a33deec46@sap.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> Message-ID: <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> Hi Christoph, OS X has a issue that needs "always" add a sin6_scope_id a multicast packet, I check that exists a old issue that logged it and add that piece of code: https://bugs.openjdk.java.net/browse/JDK-7144274 The DefaultInterface class in OS X is a plain Java class that list all interfaces and discards loopback and ppp interfaces, and prefers multistack interfaces than ones with only IPv4. I think that this class must use the network interface order defined in System Configuration but I don't find a way to use it. I already signed the OCA, then I would like to have your help. El 11/04/2018 a las 04:42, Langer, Christoph escribi?: > Hi Joel, > > your fix sounds reasonable. In fact, I'm not even sure if the sin6_scope_id should be set for multicast. Maybe it should be done only for link local addresses. > > Additionally, I guess the selection of the default interface (for IPv6) should be improved because I still can imagine a scenario where the first interface only has IPv4 but you want to do an IPv6 link local connect where you need a scope. > > Do you have signed an OCA as per [1], section "0. Become a Contributor"? Then I can help you with sponsoring this... > > Best regards > Christoph > > [1] http://openjdk.java.net/contribute/ > >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of >> Joel Pel?ez Jorge >> Sent: Dienstag, 10. April 2018 00:37 >> To: net-dev at openjdk.java.net >> Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active >> network interface without IPv6 address >> >> Hi, >> >> I am new in the OpenJDK Community and I contribute with a fix for the bug >> 8200719 related to networking in macOS system. >> >> I wrote a minimal patch that only set the scope id when the address is link- >> local or multicast. This change avoid send IPv6 packets on a wrong interface. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200719 >> >> Patch: >> >> diff -r f088ec60bed5 src/java.base/unix/native/libnet/net_util_md.c >> --- a/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 10:39:29 >> 2018 -0700 >> +++ b/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 16:50:18 >> 2018 -0500 >> @@ -89,7 +89,8 @@ >> } >> int defaultIndex; >> struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)him; >> - if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0)) { >> + if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0) && >> + (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr) || >> IN6_IS_ADDR_MULTICAST(&sin6->sin6_addr))) { >> defaultIndex = (*env)->GetStaticIntField(env, ni_class, >> ni_defaultIndexID); >> sin6->sin6_scope_id = defaultIndex; >> >> >> Thanks, >> Joel From christoph.langer at sap.com Wed Apr 11 14:44:59 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Apr 2018 14:44:59 +0000 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> Message-ID: <50722784029d48cd83da972dd6ea1736@sap.com> Hi Joel, Sounds good to me then. I created a webrev and uploaded it: http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ I will run it through the tests here at SAP and check the results. @All: Could we please get another review? Thanks Christoph > -----Original Message----- > From: Joel Pel?ez Jorge [mailto:joelpelaez at gmail.com] > Sent: Mittwoch, 11. April 2018 12:54 > To: Langer, Christoph ; net- > dev at openjdk.java.net > Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any active > network interface without IPv6 address > > Hi Christoph, > > OS X has a issue that needs "always" add a sin6_scope_id a multicast packet, I > check that exists a old issue that logged it and add that piece of code: > https://bugs.openjdk.java.net/browse/JDK-7144274 > > The DefaultInterface class in OS X is a plain Java class that list all interfaces > and discards loopback and ppp interfaces, and prefers multistack interfaces > than ones with only IPv4. I think that this class must use the network > interface order defined in System Configuration but I don't find a way to use > it. > > I already signed the OCA, then I would like to have your help. > > El 11/04/2018 a las 04:42, Langer, Christoph escribi?: > > Hi Joel, > > > > your fix sounds reasonable. In fact, I'm not even sure if the sin6_scope_id > should be set for multicast. Maybe it should be done only for link local > addresses. > > > > Additionally, I guess the selection of the default interface (for IPv6) should > be improved because I still can imagine a scenario where the first interface > only has IPv4 but you want to do an IPv6 link local connect where you need a > scope. > > > > Do you have signed an OCA as per [1], section "0. Become a Contributor"? > Then I can help you with sponsoring this... > > > > Best regards > > Christoph > > > > [1] http://openjdk.java.net/contribute/ > > > >> -----Original Message----- > >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > >> Joel Pel?ez Jorge > >> Sent: Dienstag, 10. April 2018 00:37 > >> To: net-dev at openjdk.java.net > >> Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active > >> network interface without IPv6 address > >> > >> Hi, > >> > >> I am new in the OpenJDK Community and I contribute with a fix for the > bug > >> 8200719 related to networking in macOS system. > >> > >> I wrote a minimal patch that only set the scope id when the address is > link- > >> local or multicast. This change avoid send IPv6 packets on a wrong > interface. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200719 > >> > >> Patch: > >> > >> diff -r f088ec60bed5 src/java.base/unix/native/libnet/net_util_md.c > >> --- a/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 10:39:29 > >> 2018 -0700 > >> +++ b/src/java.base/unix/native/libnet/net_util_md.c Mon Apr 09 > 16:50:18 > >> 2018 -0500 > >> @@ -89,7 +89,8 @@ > >> } > >> int defaultIndex; > >> struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)him; > >> - if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0)) { > >> + if (sin6->sin6_family == AF_INET6 && (sin6->sin6_scope_id == 0) && > >> + (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr) || > >> IN6_IS_ADDR_MULTICAST(&sin6->sin6_addr))) { > >> defaultIndex = (*env)->GetStaticIntField(env, ni_class, > >> ni_defaultIndexID); > >> sin6->sin6_scope_id = defaultIndex; > >> > >> > >> Thanks, > >> Joel From chris.hegarty at oracle.com Wed Apr 11 16:10:37 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Apr 2018 17:10:37 +0100 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <50722784029d48cd83da972dd6ea1736@sap.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> <50722784029d48cd83da972dd6ea1736@sap.com> Message-ID: <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> On 11/04/18 15:44, Langer, Christoph wrote: > Hi Joel, > > Sounds good to me then. I created a webrev and uploaded it: http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ > > I will run it through the tests here at SAP and check the results. I will run it through the test system here in Oracle too. > @All: Could we please get another review? You have my Reviewed ( subject to successful testing ). -Chris. From ecki at zusammenkunft.net Wed Apr 11 19:51:32 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 11 Apr 2018 19:51:32 +0000 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> <50722784029d48cd83da972dd6ea1736@sap.com>, <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> Message-ID: Hello, Is this really correct? This seems to break for multi-homed hosts (old and new code). Does OS X not do proper interface autoselection (and if so, would the naive approach be any good?). Shouldnt it at least try to look at the destination routes, the priorities and the lifetimes? Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: net-dev on behalf of Chris Hegarty Sent: Wednesday, April 11, 2018 6:10:37 PM To: Langer, Christoph; Joel Pel?ez Jorge; net-dev at openjdk.java.net Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address On 11/04/18 15:44, Langer, Christoph wrote: > Hi Joel, > > Sounds good to me then. I created a webrev and uploaded it: http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ > > I will run it through the tests here at SAP and check the results. I will run it through the test system here in Oracle too. > @All: Could we please get another review? You have my Reviewed ( subject to successful testing ). -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelpelaez at gmail.com Thu Apr 12 02:05:35 2018 From: joelpelaez at gmail.com (=?UTF-8?Q?Joel_Pel=c3=a1ez_Jorge?=) Date: Wed, 11 Apr 2018 21:05:35 -0500 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <50722784029d48cd83da972dd6ea1736@sap.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> <50722784029d48cd83da972dd6ea1736@sap.com> Message-ID: <7a6f7cbe-4569-122f-1dab-209a8d026cb6@gmail.com> Hi Brend, I don't want remove all code related to scope_id assignation because it can break compatibility with old software, the new code only allows unicast packets be routed by the OS. I couldn't find the reason to exists of that (old) code. Linux has a filesystem than allow to applications read the state and features of all interfaces and select the best option, but in OS X the procedure is a plain selection of a "default" interface using only Java code using a simple criteria. Sorry for reply in this way, I am not subscribed in the mailing list and I can't see message in my mailbox for a direct reply. Joel. El 11/04/2018 a las 09:44, Langer, Christoph escribi?: > Hi Joel, > > Sounds good to me then. I created a webrev and uploaded it: http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ > > I will run it through the tests here at SAP and check the results. > > @All: Could we please get another review? > > Thanks > Christoph > From vyom.tewari at oracle.com Fri Apr 13 09:50:39 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 13 Apr 2018 15:20:39 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive Message-ID: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Hi All, Please review the below code. BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html Currently Java supports SO_KEEPALIVE, whose default value is 7200 seconds which is too long for most of the applications. This code change will allow us to set the keepalive parameters(TCP_KEEPIDLE,TCP_KEEPCNT,TCP_KEEPINTVL)? which will configure the idle time on per socket basis. I did code changes for Linux & Mac only, support for other platforms can be added in future if needed. Thanks, Vyom From christoph.langer at sap.com Fri Apr 13 13:57:57 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Apr 2018 13:57:57 +0000 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> <50722784029d48cd83da972dd6ea1736@sap.com> <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> Message-ID: <2b4f8ae2ce794a2689ed81360b6a72db@sap.com> Hi Chris, Joel, testing went fine and did not show regressions. Same for the Oracle tests? Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 11. April 2018 18:11 > To: Langer, Christoph ; Joel Pel?ez Jorge > ; net-dev at openjdk.java.net > Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any active > network interface without IPv6 address > > On 11/04/18 15:44, Langer, Christoph wrote: > > Hi Joel, > > > > Sounds good to me then. I created a webrev and uploaded it: > http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ > > > > I will run it through the tests here at SAP and check the results. > > I will run it through the test system here in Oracle too. > > > @All: Could we please get another review? > > You have my Reviewed ( subject to successful testing ). > > -Chris. From chris.hegarty at oracle.com Fri Apr 13 14:06:52 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Apr 2018 15:06:52 +0100 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <2b4f8ae2ce794a2689ed81360b6a72db@sap.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> <50722784029d48cd83da972dd6ea1736@sap.com> <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> <2b4f8ae2ce794a2689ed81360b6a72db@sap.com> Message-ID: <11a3980a-cc74-218a-5e1c-eca935e4e802@oracle.com> On 13/04/18 14:57, Langer, Christoph wrote: > Hi Chris, Joel, > > testing went fine and did not show regressions. Same for the Oracle tests? Yes. nothing untoward observed. -Chris. > > Best regards > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Mittwoch, 11. April 2018 18:11 >> To: Langer, Christoph ; Joel Pel?ez Jorge >> ; net-dev at openjdk.java.net >> Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any active >> network interface without IPv6 address >> >> On 11/04/18 15:44, Langer, Christoph wrote: >>> Hi Joel, >>> >>> Sounds good to me then. I created a webrev and uploaded it: >> http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ >>> >>> I will run it through the tests here at SAP and check the results. >> >> I will run it through the test system here in Oracle too. >> >>> @All: Could we please get another review? >> >> You have my Reviewed ( subject to successful testing ). >> >> -Chris. From ecki at zusammenkunft.net Fri Apr 13 20:10:53 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 13 Apr 2018 20:10:53 +0000 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: Hello, Glad to see progress on this, much needed. I wonder if there is a better way for safe and dynamic string concatenation in the JDK, this errmsg[56] looks scary. Did you tried to support it on Windows, even if it does not support all 3 parameters it might be important to be available (I think Oracle Database supports it for DCD on Windows, too) Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: net-dev on behalf of vyom tewari Sent: Friday, April 13, 2018 11:50:39 AM To: OpenJDK Network Dev list Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive Hi All, Please review the below code. BugId : https://bugs.openjdk.java.net/browse/JDK-8194298 webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html Currently Java supports SO_KEEPALIVE, whose default value is 7200 seconds which is too long for most of the applications. This code change will allow us to set the keepalive parameters(TCP_KEEPIDLE,TCP_KEEPCNT,TCP_KEEPINTVL) which will configure the idle time on per socket basis. I did code changes for Linux & Mac only, support for other platforms can be added in future if needed. Thanks, Vyom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Sat Apr 14 03:53:09 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Sat, 14 Apr 2018 09:23:09 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: <79c5e9ca-9a4d-ed38-9474-71301281343d@oracle.com> On Saturday 14 April 2018 01:40 AM, Bernd Eckenfels wrote: > Hello, > > Glad to see progress on this, much needed. thanks > > I wonder if there is a better way for safe and dynamic string > concatenation in the JDK, this errmsg[56] looks scary. sure, i will fix it. > > Did you tried to support it on Windows, even if it does not support > all 3 parameters it might be important to be available (I think Oracle > Database supports it for DCD on Windows, too) I already mentioned in mail, support for other platform can be added in future if needed. Only "Windows 10 1709" support all three socket options(TCP_KEEPIDLE, TCP_KEEPCNT, TCP_KEEPINTVL).? These are socket options, we want set/get both, I tried to implement? keepalive times using WSAloctl (https://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx) but? it is not possible to get the current *SIO_KEEPALIVE_VALS* for a socket, MSDN says that WSAIoctl output buffer is not used. Thanks, Vyom > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* net-dev on behalf of vyom > tewari > *Sent:* Friday, April 13, 2018 11:50:39 AM > *To:* OpenJDK Network Dev list > *Subject:* RFR:8194298 Add support for per Socket configuration of TCP > keepalive > Hi All, > > Please review the below code. > > BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 > > webrev : > http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > > > Currently Java supports SO_KEEPALIVE, whose default value is 7200 > seconds which is too long for most of the applications. This code change > will allow us to set the keepalive > parameters(TCP_KEEPIDLE,TCP_KEEPCNT,TCP_KEEPINTVL)? which will configure > the idle time on per socket basis. > > I did code changes for Linux & Mac only, support for other platforms can > be added in future if needed. > > Thanks, > > Vyom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Apr 14 07:09:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Apr 2018 08:09:35 +0100 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: <6a0dd9ee-9d0e-643b-1494-2f543a638149@oracle.com> On 13/04/2018 10:50, vyom tewari wrote: > Hi All, > > Please review the below code. > > BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 > > webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > > Currently Java supports SO_KEEPALIVE, whose default value is 7200 > seconds which is too long for most of the applications. This code > change will allow us to set the keepalive > parameters(TCP_KEEPIDLE,TCP_KEEPCNT,TCP_KEEPINTVL)? which will > configure the idle time on per socket basis. > > I did code changes for Linux & Mac only, support for other platforms > can be added in future if needed. Limiting this to specific platforms is okay but I think their descriptions will need a bit to work to ensure there is enough wriggle room to support varying behavior and also be somewhat consistent with the wording that we use for other options. There are several points that will need to expanded in the javadoc and maybe the style/wording in java.net.StandardSocketOption#SO_KEEPALIVE would help get that somewhat consistent -- e.g. initial value, can be set on unbound socket, can be changed after being set, etc. One concern is that you've chosen to support it on ServerSocket and specify that it can be "inherited" by the sockets for accepted connections. This isn't tested in the proposed tests and I'm wondering if we would be saner to limit this to connected sockets. Can you update SocketChannel/SocketOptionTests.java to ensure that SocketChannel is test? We also need to ensure that the new options don't show up in the supportedOptions returned by the channels that don't support these new options. In passing:? The ordering of the modifiers in XXXSocketOptions looks a bit odd, can this be changed to the more usual "private static native". -Alan From Alan.Bateman at oracle.com Sun Apr 15 08:03:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Apr 2018 09:03:58 +0100 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <6a0dd9ee-9d0e-643b-1494-2f543a638149@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> <6a0dd9ee-9d0e-643b-1494-2f543a638149@oracle.com> Message-ID: <5ecbbdb5-4d62-4854-bd55-6d828744fbe6@oracle.com> On 14/04/2018 08:09, Alan Bateman wrote: > : > > Can you update SocketChannel/SocketOptionTests.java to ensure that > SocketChannel is test? We also need to ensure that the new options > don't show up in the supportedOptions returned by the channels that > don't support these new options. Just on this point, I think this needs work in ExtendedSocketOptions so that the extended options are organized by socket type (STREAM or DGRAM). This will become a lot more obvious once you add tests for SocketChannel as its implementation will need a change to pick up the extended options for STREAM sockets. It will also avoid the filtering in PlainDatagramSocketImpl that you've added to work around the issue there. -Alan From vyom.tewari at oracle.com Sun Apr 15 13:17:46 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Sun, 15 Apr 2018 18:47:46 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <5ecbbdb5-4d62-4854-bd55-6d828744fbe6@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> <6a0dd9ee-9d0e-643b-1494-2f543a638149@oracle.com> <5ecbbdb5-4d62-4854-bd55-6d828744fbe6@oracle.com> Message-ID: <289b857c-e299-5319-cbbe-aaa8a8908848@oracle.com> On Sunday 15 April 2018 01:33 PM, Alan Bateman wrote: > On 14/04/2018 08:09, Alan Bateman wrote: >> : >> >> Can you update SocketChannel/SocketOptionTests.java to ensure that >> SocketChannel is test? We also need to ensure that the new options >> don't show up in the supportedOptions returned by the channels that >> don't support these new options. > Just on this point, I think this needs work in ExtendedSocketOptions > so that the extended options are organized by socket type (STREAM or > DGRAM). This will become a lot more obvious once you add tests for > SocketChannel as its implementation will need a change to pick up the > extended options for STREAM sockets. It will also avoid the filtering > in PlainDatagramSocketImpl that you've added to work around the issue > there. Even i thought the same, when i added TCP_QUICKACK but somehow i choose not to do at that time. I will modify the tests? and will? do the other changes suggested by you. Vyom > > -Alan From sshamaia at in.ibm.com Mon Apr 16 08:44:24 2018 From: sshamaia at in.ibm.com (Srividya Shamaiah) Date: Mon, 16 Apr 2018 14:14:24 +0530 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: Message-ID: Hi Chris, Please review the attached patch in http://cr.openjdk.java.net/~mhorie/8201369/webrev/ Can you also backport this to JDK 8, we have customers waiting for this fix at JDK 8 level. Thanks, Srividya S From: Srividya Shamaiah/India/IBM To: "Langer, Christoph" Cc: Chris Hegarty , OpenJDK Network Dev list Date: 11/04/2018 03:35 PM Subject: RE: 8169865 : Changes not ported to IPv4 Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, Srividya S From: "Langer, Christoph" To: Srividya Shamaiah , Chris Hegarty Cc: OpenJDK Network Dev list Date: 11/04/2018 02:51 PM Subject: RE: 8169865 : Changes not ported to IPv4 Hi Srividya, I would also welcome this fix. Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Srividya Shamaiah Sent: Mittwoch, 11. April 2018 09:19 To: Chris Hegarty Cc: OpenJDK Network Dev list Subject: Re: 8169865 : Changes not ported to IPv4 Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S Inactive hide details for Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah On 10 Apr 2018, at 12:34, Srividya Shamaiah < sshamaia at in.ibm.com> wrote: > From: Chris Hegarty To: Srividya Shamaiah Cc: OpenJDK Network Dev list Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 > On 10 Apr 2018, at 12:34, Srividya Shamaiah wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From christoph.langer at sap.com Mon Apr 16 09:19:26 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Apr 2018 09:19:26 +0000 Subject: JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <11a3980a-cc74-218a-5e1c-eca935e4e802@oracle.com> References: <2add150d-ba6c-a177-b389-875d02d7fdd6@gmail.com> <3213e968c9794f579d87cd3a33deec46@sap.com> <27a126fe-8d80-6001-545e-a91910e31947@gmail.com> <50722784029d48cd83da972dd6ea1736@sap.com> <849f0d71-0cfd-29b3-6e14-c73869ea83dc@oracle.com> <2b4f8ae2ce794a2689ed81360b6a72db@sap.com> <11a3980a-cc74-218a-5e1c-eca935e4e802@oracle.com> Message-ID: <5aebb6b606b943d2b380402f12433fea@sap.com> Hi, thanks, I've pushed it then: http://hg.openjdk.java.net/jdk/jdk/rev/bc1c7e41e285 Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Freitag, 13. April 2018 16:07 > To: Langer, Christoph ; Joel Pel?ez Jorge > ; net-dev at openjdk.java.net > Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any active > network interface without IPv6 address > > On 13/04/18 14:57, Langer, Christoph wrote: > > Hi Chris, Joel, > > > > testing went fine and did not show regressions. Same for the Oracle tests? > > Yes. nothing untoward observed. > > -Chris. > > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Mittwoch, 11. April 2018 18:11 > >> To: Langer, Christoph ; Joel Pel?ez Jorge > >> ; net-dev at openjdk.java.net > >> Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any > active > >> network interface without IPv6 address > >> > >> On 11/04/18 15:44, Langer, Christoph wrote: > >>> Hi Joel, > >>> > >>> Sounds good to me then. I created a webrev and uploaded it: > >> http://cr.openjdk.java.net/~clanger/webrevs/8200719.0/ > >>> > >>> I will run it through the tests here at SAP and check the results. > >> > >> I will run it through the test system here in Oracle too. > >> > >>> @All: Could we please get another review? > >> > >> You have my Reviewed ( subject to successful testing ). > >> > >> -Chris. From christoph.langer at sap.com Mon Apr 16 09:29:29 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Apr 2018 09:29:29 +0000 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: Message-ID: Hi Srividya, thanks for doing this work. Change looks good from my side, except for a small indentation flaw in lines 91 and 94 and the copyright year that needs to be adjusted. But I can fix this when I push it. Let's wait for another review (Chris) before we can push it. I'll also do some testing. I'll also take care of the backport after the push to jdk11. Best regards Christoph From: Srividya Shamaiah [mailto:sshamaia at in.ibm.com] Sent: Montag, 16. April 2018 10:44 To: Langer, Christoph Cc: Chris Hegarty ; OpenJDK Network Dev list Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only Hi Chris, Please review the attached patch in http://cr.openjdk.java.net/~mhorie/8201369/webrev/ Can you also backport this to JDK 8, we have customers waiting for this fix at JDK 8 level. Thanks, Srividya S [Inactive hide details for Srividya Shamaiah---11/04/2018 03:35:38 PM---Thanks Chris , As you suggested, I will provide the patc]Srividya Shamaiah---11/04/2018 03:35:38 PM---Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, From: Srividya Shamaiah/India/IBM To: "Langer, Christoph" > Cc: Chris Hegarty >, OpenJDK Network Dev list > Date: 11/04/2018 03:35 PM Subject: RE: 8169865 : Changes not ported to IPv4 ________________________________ Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, Srividya S [Inactive hide details for "Langer, Christoph" ---11/04/2018 02:51:51 PM---Hi Srividya, I would also welcome this fix.]"Langer, Christoph" ---11/04/2018 02:51:51 PM---Hi Srividya, I would also welcome this fix. From: "Langer, Christoph" > To: Srividya Shamaiah >, Chris Hegarty > Cc: OpenJDK Network Dev list > Date: 11/04/2018 02:51 PM Subject: RE: 8169865 : Changes not ported to IPv4 ________________________________ Hi Srividya, I would also welcome this fix. Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Srividya Shamaiah Sent: Mittwoch, 11. April 2018 09:19 To: Chris Hegarty > Cc: OpenJDK Network Dev list > Subject: Re: 8169865 : Changes not ported to IPv4 Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S [Inactive hide details for Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > From: Chris Hegarty > To: Srividya Shamaiah > Cc: OpenJDK Network Dev list > Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 ________________________________ > On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: image001.gif URL: From vyom.tewari at oracle.com Mon Apr 16 09:36:43 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Mon, 16 Apr 2018 15:06:43 +0530 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: Message-ID: looks good to me, As Christoph already mentioned just update the copyright date. Vyom On Monday 16 April 2018 02:14 PM, Srividya Shamaiah wrote: > > Hi Chris, > Please review the attached patch in > http://cr.openjdk.java.net/~mhorie/8201369/webrev/ > > > Can you also backport this to JDK 8, we have customers waiting for > this fix at JDK 8 level. > > Thanks, > Srividya S > > Inactive hide details for Srividya Shamaiah---11/04/2018 03:35:38 > PM---Thanks Chris , As you suggested, I will provide the patcSrividya > Shamaiah---11/04/2018 03:35:38 PM---Thanks Chris , As you suggested, I > will provide the patch based on jdk 11. Thanks, > > From: Srividya Shamaiah/India/IBM > To: "Langer, Christoph" > Cc: Chris Hegarty , OpenJDK Network Dev list > > Date: 11/04/2018 03:35 PM > Subject: RE: 8169865 : Changes not ported to IPv4 > > ------------------------------------------------------------------------ > > > Thanks Chris , As you suggested, I will provide the patch based on jdk 11. > > Thanks, > Srividya S > > > Inactive hide details for "Langer, Christoph" ---11/04/2018 02:51:51 > PM---Hi Srividya, I would also welcome this fix."Langer, Christoph" > ---11/04/2018 02:51:51 PM---Hi Srividya, I would also welcome this fix. > > From: "Langer, Christoph" > To: Srividya Shamaiah , Chris Hegarty > > Cc: OpenJDK Network Dev list > Date: 11/04/2018 02:51 PM > Subject: RE: 8169865 : Changes not ported to IPv4 > ------------------------------------------------------------------------ > > > > Hi Srividya, > > I would also welcome this fix. > > Will you do the fix based on the jdk (11) depot? I think > Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly > the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can > assist you with sponsoring/backporting to JDK8, if you like. > > Best regards > Christoph > > > > *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On Behalf Of > *Srividya Shamaiah* > Sent:*Mittwoch, 11. April 2018 09:19* > To:*Chris Hegarty * > Cc:*OpenJDK Network Dev list * > Subject:*Re: 8169865 : Changes not ported to IPv4 > > Thank you Chris for opening the JIRA bug, I will work on the fix and > contribute it . > > Thanks, > Srividya S > > Inactive hide details for Chris Hegarty ---10/04/2018 08:51:05 PM---> > On 10 Apr 2018, at 12:34, Srividya Shamaiah ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya > Shamaiah <_sshamaia at in.ibm.com_ > wrote: > > > From: Chris Hegarty <_chris.hegarty at oracle.com_ > > > To: Srividya Shamaiah <_sshamaia at in.ibm.com_ > > Cc: OpenJDK Network Dev list <_net-dev at openjdk.java.net_ > > > Date: 10/04/2018 08:51 PM > Subject: Re: 8169865 : Changes not ported to IPv4 > > ------------------------------------------------------------------------ > > > > > > > On 10 Apr 2018, at 12:34, Srividya Shamaiah <_sshamaia at in.ibm.com_ > > wrote: > > > > Hi Chris, > > > > One of our customer reported a similar issue and the issue can be > resolved through the bug fix 8169865 which was include at 8u152 level. > We were looking this issue from AIX perspective as it did not do the > reverse lookup with bug fix 8169865 (as reverse lookup is limited to > solaris after the bug fix). > > > > While implementing the fix, we want to make sure the fix works for > all scenario. As there is an inconsistency between IPv6 and IPv4 after > 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we > are afraid whether customer can hit the same issue if they use IPv4. > > > > Please confirm whether it makes sense to remove the reverse lookup > of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing > is consistent for those platforms. > > Yes, I believe it does. > > I filed the follow JIRA issue to track this: > _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e=_ > > -Chris. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From christoph.langer at sap.com Mon Apr 16 09:54:17 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Apr 2018 09:54:17 +0000 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: <0f7c1d2ab8c742e3a956dbe1051c66a0@sap.com> Hi Vyom, I had a quick glance through your changes. Apart from the suggestions you've already got (use snprintf instead of string concatenation, method ordering...), I think "src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java" and " src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c " should be renamed to MacOSXSocketOptions. to be consistent with the other platforms (Linux and Solaris at the moment). Furthermore, I think most of the options can/should also be supported for AIX. I'm willing to contribute this. However, I should probably do this in a separate bug once you have completed your work on this one. I would also add TCP QUICKACK then. Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > vyom tewari > Sent: Freitag, 13. April 2018 11:51 > To: OpenJDK Network Dev list > Subject: RFR:8194298 Add support for per Socket configuration of TCP > keepalive > > Hi All, > > Please review the below code. > > BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 > > webrev : > http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > > Currently Java supports SO_KEEPALIVE, whose default value is 7200 > seconds which is too long for most of the applications. This code change > will allow us to set the keepalive > parameters(TCP_KEEPIDLE,TCP_KEEPCNT,TCP_KEEPINTVL)? which will > configure > the idle time on per socket basis. > > I did code changes for Linux & Mac only, support for other platforms can > be added in future if needed. > > Thanks, > > Vyom From chris.hegarty at oracle.com Mon Apr 16 14:39:18 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Apr 2018 15:39:18 +0100 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: Message-ID: > On 16 Apr 2018, at 10:29, Langer, Christoph wrote: > > Hi Srividya, > > thanks for doing this work. > > Change looks good from my side, except for a small indentation flaw in lines 91 and 94 and the copyright year that needs to be adjusted. But I can fix this when I push it. +1 > Let?s wait for another review (Chris) before we can push it. I?ll also do some testing. I?ll run some tests with this patch too. > I?ll also take care of the backport after the push to jdk11. Yes. Let?s first push this to jdk/jdk, then follow up with a back port request as appropriate. -Chris. > Best regards > Christoph > ? <> > From: Srividya Shamaiah [mailto:sshamaia at in.ibm.com ] > Sent: Montag, 16. April 2018 10:44 > To: Langer, Christoph > > Cc: Chris Hegarty >; OpenJDK Network Dev list > > Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only > > Hi Chris, > Please review the attached patch in > http://cr.openjdk.java.net/~mhorie/8201369/webrev/ > > Can you also backport this to JDK 8, we have customers waiting for this fix at JDK 8 level. > > Thanks, > Srividya S > > Srividya Shamaiah---11/04/2018 03:35:38 PM---Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, > > From: Srividya Shamaiah/India/IBM > To: "Langer, Christoph" > > Cc: Chris Hegarty >, OpenJDK Network Dev list > > Date: 11/04/2018 03:35 PM > Subject: RE: 8169865 : Changes not ported to IPv4 > > > > Thanks Chris , As you suggested, I will provide the patch based on jdk 11. > > Thanks, > Srividya S > > > "Langer, Christoph" ---11/04/2018 02:51:51 PM---Hi Srividya, I would also welcome this fix. > > From: "Langer, Christoph" > > To: Srividya Shamaiah >, Chris Hegarty > > Cc: OpenJDK Network Dev list > > Date: 11/04/2018 02:51 PM > Subject: RE: 8169865 : Changes not ported to IPv4 > > > > Hi Srividya, > > I would also welcome this fix. > > Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. > > Best regards > Christoph > > > > From: net-dev [mailto:net-dev-bounces at openjdk.java.net ] On Behalf Of Srividya Shamaiah > Sent: Mittwoch, 11. April 2018 09:19 > To: Chris Hegarty > > Cc: OpenJDK Network Dev list > > Subject: Re: 8169865 : Changes not ported to IPv4 > Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . > > Thanks, > Srividya S > > Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > > > From: Chris Hegarty > > To: Srividya Shamaiah > > Cc: OpenJDK Network Dev list > > Date: 10/04/2018 08:51 PM > Subject: Re: 8169865 : Changes not ported to IPv4 > > > > > > > > On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > > > > Hi Chris, > > > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. > > Yes, I believe it does. > > I filed the follow JIRA issue to track this: > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= > > -Chris. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Mon Apr 16 16:29:20 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 16 Apr 2018 09:29:20 -0700 Subject: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] Message-ID: Hello! After integrating the fix for JDK-8198358 there are only a few differences left in these two implementations, so it is relatively easy to merge them together. Some cleanup was done along the way: - unused argument in socket0() was removed, - tests of the IP family were moved from native code to Java layer, - SetHandleInformation((HANDLE)(UINT_PTR)fd, HANDLE_FLAG_INHERIT, FALSE) was removed from socket0 (as it is already done inside NET_Socket()), - if (WSAGetLastError() == -2) branch removed from accept0(), as it can never succeed anyway (in TwoStacks it was testing for newfd == -2, which doesn't seem correct either), - in accept0() added a check if (*env)->NewObject() was unsuccessful. Also a regression test was added to verify that bind() and connect() reject Inet6Address when the system option java.net.preferIPv4Stack is set to true. The patched JDK was successfully built and all the tests, including the new one, passed well. The new test also passed well on all other platforms. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8201510 WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From chris.hegarty at oracle.com Mon Apr 16 17:09:02 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Apr 2018 18:09:02 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: Hi, Here are refreshed links to the latest code in the sandbox: http://cr.openjdk.java.net/~chegar/httpclient/03/javadoc/api/java.net.http/module-summary.html http://cr.openjdk.java.net/~chegar/httpclient/03/webrev/ Includes: a) Changes to address the two issues raised by Simone during the JEP Propose To Target [1] [2]. b) Changes to address review comments from dfuchs, prappo, michaelm, and chegar [3]. c) Several bug fixes, additional test coverage, and stability improvements. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8201325 [2] https://bugs.openjdk.java.net/browse/JDK-8201361 [3] http://hg.openjdk.java.net/jdk/sandbox/log?revcount=80&rev=desc%28%22review+comment%22%29+and+branch%28%22http-client-branch%22%29+and+date%28%22%3E2018-02-01%22%29 On 21/03/18 20:33, Chris Hegarty wrote: > Hi, > > This is a request for review for the HTTP Client implementation - JEP 321. > > The javadoc link has been refreshed, based on feedback received from > the CSR [1] ( and a follow on supplementary CSR [2] ): > http://cr.openjdk.java.net/~chegar/httpclient/02/javadoc/api/java.net.http/java/net/http/package-summary.html > > The webrev link has been refreshed to include implementation changes > to support the latest API, additional test code coverage and scenarios: > http://cr.openjdk.java.net/~chegar/httpclient/02/webrev/ > >> On 9 Feb 2018, at 14:33, Chris Hegarty wrote: >> Development of the JDK HTTP Client, incubated in JDK 9 and re-incubated >> in JDK 10, has continued. It will soon be in a position to be proposed >> for inclusion in Java 11, through JEP 321. This will proceed, as usual, >> through the JEP 2.0 process. >> >> JEP 321 has recently been updated with the proposed package and module >> name, `java.net.http`. The code in the sandbox has been updated to >> reflect this. >> >> Javadoc based on the latest code in the sandbox: >> http://cr.openjdk.java.net/~chegar/httpclient/00/javadoc/api/java.net.http-summary.html >> >> Webrev based on the latest code in the sandbox: >> http://cr.openjdk.java.net/~chegar/httpclient/00/webrev/ >> >> ( much of the changes in the webrev are mechanical due to renaming, but >> there are stability fixes and the API documentation has been >> reorganized to improve readability ) >> >> More information about the JDK HTTP Client can be found on the >> networking groups page. >> http://openjdk.java.net/groups/net/httpclient/ > > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8197565 > [2] https://bugs.openjdk.java.net/browse/JDK-8199938 > From simone.bordet at gmail.com Mon Apr 16 17:47:21 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 16 Apr 2018 19:47:21 +0200 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: Chris, On Mon, Apr 16, 2018 at 7:09 PM, Chris Hegarty wrote: > Hi, > > Here are refreshed links to the latest code in the sandbox: > > http://cr.openjdk.java.net/~chegar/httpclient/03/javadoc/api/java.net.http/module-summary.html > http://cr.openjdk.java.net/~chegar/httpclient/03/webrev/ > > Includes: > > a) Changes to address the two issues raised by Simone during > the JEP Propose To Target [1] [2]. > > b) Changes to address review comments from dfuchs, prappo, > michaelm, and chegar [3]. > > c) Several bug fixes, additional test coverage, and stability > improvements. Out of curiosity, is this code implementing the ReactiveStreams TCK (in its Flow declination) ? I ask because I have recently implemented it for Jetty's Reactive HttpClient (https://github.com/jetty-project/jetty-reactive-httpclient) and found a few surprising failures. It will be great if this can be done because all ReactiveStreams implementations implement the ReactiveStreams TCK, and so there is an assumed baseline of how these libraries should work that is beneficial for interoperability. The effort is not much: each Publisher/Processor/Subscriber implementation should just extend a ReactiveStream TCK class overriding a few methods, for example: https://github.com/jetty-project/jetty-reactive-httpclient/blob/master/src/test/java/org/eclipse/jetty/reactive/client/internal/QueuedSinglePublisherTCKTest.java The ReactiveStreams TCK does the rest. Thanks ! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From felix.yang at oracle.com Tue Apr 17 03:34:25 2018 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 17 Apr 2018 11:34:25 +0800 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* Message-ID: Hi all, ?? please review the following patch to apply NetworkConfiguration library to exclude point-to-point interfaces. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8194260 Webrev: ??? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ Thanks, Felix From vyom.tewari at oracle.com Tue Apr 17 06:21:41 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 17 Apr 2018 11:51:41 +0530 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* In-Reply-To: References: Message-ID: Hi Felix, Looks good to me, minor bit, please fix the tag order in all the tests, @summary should come immediately after @bug. In Tests.java there are unused imports(import java.net.*, java.io.*) can you please change it to use explicit classes. Thanks, Vyom On Tuesday 17 April 2018 09:04 AM, Felix Yang wrote: > Hi all, > > ?? please review the following patch to apply NetworkConfiguration > library to exclude point-to-point interfaces. > > Bug: > > ??? https://bugs.openjdk.java.net/browse/JDK-8194260 > > Webrev: > > ??? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ > > Thanks, > > Felix > From chris.hegarty at oracle.com Tue Apr 17 08:25:52 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Apr 2018 09:25:52 +0100 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* In-Reply-To: References: Message-ID: > On 17 Apr 2018, at 04:34, Felix Yang wrote: > ... > http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ Thanks for doing this Felix. Mainly looks good. Just a few comments. The old test runs on systems without IPv4 or IPv6 configured. So I think the Optional `get` should be replaced with `orElse`. Either that or update usage to check for the presence of a value in the Optional. The old test filters out the loopback address, in order to get ?real? addresses. I think we should preserve this behaviour. Other filtering is done in the old tests too, but I don?t think it is really needed. --- diff --git a/test/jdk/java/net/ipv6tests/Tests.java b/test/jdk/java/net/ipv6tests/Tests.java --- a/test/jdk/java/net/ipv6tests/Tests.java +++ b/test/jdk/java/net/ipv6tests/Tests.java @@ -178,26 +178,28 @@ } public static Inet4Address getFirstLocalIPv4Address () { - return getNetworkConfig().ip4Addresses() - .findFirst() - .get(); + return networkConfig.ip4Addresses() + .filter(a -> !a.isLoopbackAddress()) + .findFirst() + .orElse(null); } public static Inet6Address getFirstLocalIPv6Address () { - return getNetworkConfig().ip6Addresses() - .findFirst() - .get(); + return networkConfig.ip6Addresses() + .filter(a -> !a.isLoopbackAddress()) + .findFirst() + .orElse(null); } + private static NetworkConfiguration networkConfig = getNetworkConfig(); + private static NetworkConfiguration getNetworkConfig() { - NetworkConfiguration cfg = null; try { - cfg = NetworkConfiguration.probe(); + return NetworkConfiguration.probe(); } catch (IOException e) { System.out.println("Failed to probe NetworkConfiguration"); throw new RuntimeException(e); } - return cfg; } -Chris. From chris.hegarty at oracle.com Tue Apr 17 08:55:54 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Apr 2018 09:55:54 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> Message-ID: <846D1EE4-D326-4AF2-8CC1-B161DCE70ADE@oracle.com> Simone, > On 16 Apr 2018, at 18:47, Simone Bordet wrote: > >> ... > > Out of curiosity, is this code implementing the ReactiveStreams TCK > (in its Flow declination) ? The code should be compliant with the RS TCK. > I ask because I have recently implemented it for Jetty's Reactive > HttpClient (https://github.com/jetty-project/jetty-reactive-httpclient) > and found a few surprising failures. If you encounter failures can you please report those to us, since we are not aware of such. > It will be great if this can be done because all ReactiveStreams > implementations implement the ReactiveStreams TCK, and so there is an > assumed baseline of how these libraries should work that is beneficial > for interoperability. Of course, interoperability is of utmost importance. > The effort is not much: each Publisher/Processor/Subscriber > implementation should just extend a ReactiveStream TCK class > overriding a few methods, for example: > https://github.com/jetty-project/jetty-reactive-httpclient/blob/master/src/test/java/org/eclipse/jetty/reactive/client/internal/QueuedSinglePublisherTCKTest.java There is technical and non-technical effort required. It is non-trivial. That said, we?re making every effort possible to move this forward. -Chris. From viktor.klang at gmail.com Tue Apr 17 16:52:07 2018 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 17 Apr 2018 17:52:07 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: <846D1EE4-D326-4AF2-8CC1-B161DCE70ADE@oracle.com> References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> <846D1EE4-D326-4AF2-8CC1-B161DCE70ADE@oracle.com> Message-ID: On Tue, Apr 17, 2018 at 9:55 AM, Chris Hegarty wrote: > Simone, > > > On 16 Apr 2018, at 18:47, Simone Bordet wrote: > > > >> ... > > > > Out of curiosity, is this code implementing the ReactiveStreams TCK > > (in its Flow declination) ? > > The code should be compliant with the RS TCK. > > > I ask because I have recently implemented it for Jetty's Reactive > > HttpClient (https://github.com/jetty-project/jetty-reactive-httpclient) > > and found a few surprising failures. > > If you encounter failures can you please report those to us, since > we are not aware of such. > > > It will be great if this can be done because all ReactiveStreams > > implementations implement the ReactiveStreams TCK, and so there is an > > assumed baseline of how these libraries should work that is beneficial > > for interoperability. > > Of course, interoperability is of utmost importance. > > > The effort is not much: each Publisher/Processor/Subscriber > > implementation should just extend a ReactiveStream TCK class > > overriding a few methods, for example: > > https://github.com/jetty-project/jetty-reactive- > httpclient/blob/master/src/test/java/org/eclipse/jetty/ > reactive/client/internal/QueuedSinglePublisherTCKTest.java > > There is technical and non-technical effort required. It is non-trivial. > That said, we?re making every effort possible to move this forward. > Hi Chris, how can we help? > > -Chris. > > -- Cheers, ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Apr 17 17:28:20 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Apr 2018 18:28:20 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> <846D1EE4-D326-4AF2-8CC1-B161DCE70ADE@oracle.com> Message-ID: <836E11D0-0127-4192-AE03-0E8793B4AA19@oracle.com> On 17 Apr 2018, at 17:52, Viktor Klang wrote: > ... > There is technical and non-technical effort required. It is non-trivial. > That said, we?re making every effort possible to move this forward. > > Hi Chris, > > how can we help? Thank you for asking, but I think we have it under control. I hope to have news on this in the next couple of weeks. -Chris. From viktor.klang at gmail.com Tue Apr 17 17:47:25 2018 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 17 Apr 2018 18:47:25 +0100 Subject: RFR [11] 8197564: HTTP Client implementation - JEP 321 In-Reply-To: <836E11D0-0127-4192-AE03-0E8793B4AA19@oracle.com> References: <6fc14dd6-8dc1-6073-5a51-872e71321810@oracle.com> <23EEF0A3-99EB-4CD6-93B3-5F0B14C87FA2@oracle.com> <846D1EE4-D326-4AF2-8CC1-B161DCE70ADE@oracle.com> <836E11D0-0127-4192-AE03-0E8793B4AA19@oracle.com> Message-ID: On Tue, Apr 17, 2018 at 6:28 PM, Chris Hegarty wrote: > On 17 Apr 2018, at 17:52, Viktor Klang wrote: > > ... > > There is technical and non-technical effort required. It is non-trivial. > > That said, we?re making every effort possible to move this forward. > > > > Hi Chris, > > > > how can we help? > > Thank you for asking, but I think we have it under control. I hope > to have news on this in the next couple of weeks. > Ok! > > -Chris. -- Cheers, ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.yang at oracle.com Wed Apr 18 05:35:02 2018 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 18 Apr 2018 13:35:02 +0800 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* In-Reply-To: References: Message-ID: <201e30e4-7261-482c-cae1-e2cc97028488@oracle.com> Hi Chris and Wyom, ??? fixed as commented.? Updated webrev: ??? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.01/ Thanks, Felix On 2018/4/17 16:25, Chris Hegarty wrote: >> On 17 Apr 2018, at 04:34, Felix Yang wrote: >> ... >> http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ > Thanks for doing this Felix. Mainly looks good. Just a few comments. > > The old test runs on systems without IPv4 or IPv6 configured. So > I think the Optional `get` should be replaced with `orElse`. Either that > or update usage to check for the presence of a value in the Optional. > > The old test filters out the loopback address, in order to get ?real? > addresses. I think we should preserve this behaviour. Other filtering > is done in the old tests too, but I don?t think it is really needed. > > --- > diff --git a/test/jdk/java/net/ipv6tests/Tests.java b/test/jdk/java/net/ipv6tests/Tests.java > --- a/test/jdk/java/net/ipv6tests/Tests.java > +++ b/test/jdk/java/net/ipv6tests/Tests.java > @@ -178,26 +178,28 @@ > } > > public static Inet4Address getFirstLocalIPv4Address () { > - return getNetworkConfig().ip4Addresses() > - .findFirst() > - .get(); > + return networkConfig.ip4Addresses() > + .filter(a -> !a.isLoopbackAddress()) > + .findFirst() > + .orElse(null); > } > > public static Inet6Address getFirstLocalIPv6Address () { > - return getNetworkConfig().ip6Addresses() > - .findFirst() > - .get(); > + return networkConfig.ip6Addresses() > + .filter(a -> !a.isLoopbackAddress()) > + .findFirst() > + .orElse(null); > } > > + private static NetworkConfiguration networkConfig = getNetworkConfig(); > + > private static NetworkConfiguration getNetworkConfig() { > - NetworkConfiguration cfg = null; > try { > - cfg = NetworkConfiguration.probe(); > + return NetworkConfiguration.probe(); > } catch (IOException e) { > System.out.println("Failed to probe NetworkConfiguration"); > throw new RuntimeException(e); > } > - return cfg; > } > > -Chris. From chris.hegarty at oracle.com Wed Apr 18 06:02:36 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 18 Apr 2018 07:02:36 +0100 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* In-Reply-To: <201e30e4-7261-482c-cae1-e2cc97028488@oracle.com> References: <201e30e4-7261-482c-cae1-e2cc97028488@oracle.com> Message-ID: <48F868E4-AF1A-47AD-A2D7-32AC28F1E9D5@oracle.com> > On 18 Apr 2018, at 06:35, Felix Yang wrote: > > Hi Chris and Wyom, > > fixed as commented. Updated webrev: > > http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.01/ Looks good, -Chris. > Thanks, > Felix > On 2018/4/17 16:25, Chris Hegarty wrote: >>> On 17 Apr 2018, at 04:34, Felix Yang wrote: >>> ... >>> http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ >> Thanks for doing this Felix. Mainly looks good. Just a few comments. >> >> The old test runs on systems without IPv4 or IPv6 configured. So >> I think the Optional `get` should be replaced with `orElse`. Either that >> or update usage to check for the presence of a value in the Optional. >> >> The old test filters out the loopback address, in order to get ?real? >> addresses. I think we should preserve this behaviour. Other filtering >> is done in the old tests too, but I don?t think it is really needed. >> >> --- >> diff --git a/test/jdk/java/net/ipv6tests/Tests.java b/test/jdk/java/net/ipv6tests/Tests.java >> --- a/test/jdk/java/net/ipv6tests/Tests.java >> +++ b/test/jdk/java/net/ipv6tests/Tests.java >> @@ -178,26 +178,28 @@ >> } >> public static Inet4Address getFirstLocalIPv4Address () { >> - return getNetworkConfig().ip4Addresses() >> - .findFirst() >> - .get(); >> + return networkConfig.ip4Addresses() >> + .filter(a -> !a.isLoopbackAddress()) >> + .findFirst() >> + .orElse(null); >> } >> public static Inet6Address getFirstLocalIPv6Address () { >> - return getNetworkConfig().ip6Addresses() >> - .findFirst() >> - .get(); >> + return networkConfig.ip6Addresses() >> + .filter(a -> !a.isLoopbackAddress()) >> + .findFirst() >> + .orElse(null); >> } >> + private static NetworkConfiguration networkConfig = getNetworkConfig(); >> + >> private static NetworkConfiguration getNetworkConfig() { >> - NetworkConfiguration cfg = null; >> try { >> - cfg = NetworkConfiguration.probe(); >> + return NetworkConfiguration.probe(); >> } catch (IOException e) { >> System.out.println("Failed to probe NetworkConfiguration"); >> throw new RuntimeException(e); >> } >> - return cfg; >> } >> -Chris. > From vyom.tewari at oracle.com Wed Apr 18 06:07:29 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Wed, 18 Apr 2018 11:37:29 +0530 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* In-Reply-To: <201e30e4-7261-482c-cae1-e2cc97028488@oracle.com> References: <201e30e4-7261-482c-cae1-e2cc97028488@oracle.com> Message-ID: Hi Felix, latest code looks good to me, personally i prefer to throw exception instead returning null, but i can see that old code was also returning null. Hopping the code which invokes getFirstLocalIPv4Address, getFirstLocalIPv6Addres already taken care of null. Thanks, Vyom On Wednesday 18 April 2018 11:05 AM, Felix Yang wrote: > Hi Chris and Wyom, > > ??? fixed as commented.? Updated webrev: > > ??? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.01/ > > Thanks, > Felix > On 2018/4/17 16:25, Chris Hegarty wrote: >>> On 17 Apr 2018, at 04:34, Felix Yang wrote: >>> ... >>> ???? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ >> Thanks for doing this Felix. Mainly looks good. Just a few comments. >> >> The old test runs on systems without IPv4 or IPv6 configured. So >> I think the Optional `get` should be replaced with `orElse`. Either that >> or update usage to check for the presence of a value in the Optional. >> >> The old test filters out the loopback address, in order to get ?real? >> addresses. I think we should preserve this behaviour. Other filtering >> is done in the old tests too, but I don?t think it is really needed. >> >> --- >> diff --git a/test/jdk/java/net/ipv6tests/Tests.java >> b/test/jdk/java/net/ipv6tests/Tests.java >> --- a/test/jdk/java/net/ipv6tests/Tests.java >> +++ b/test/jdk/java/net/ipv6tests/Tests.java >> @@ -178,26 +178,28 @@ >> ????? } >> ? ????? public static Inet4Address getFirstLocalIPv4Address () { >> -??????? return getNetworkConfig().ip4Addresses() >> -???????????????????????????????? .findFirst() >> -???????????????????????????????? .get(); >> +??????? return networkConfig.ip4Addresses() >> +???????????????????????????? .filter(a -> !a.isLoopbackAddress()) >> +???????????????????????????? .findFirst() >> +???????????????????????????? .orElse(null); >> ????? } >> ? ????? public static Inet6Address getFirstLocalIPv6Address () { >> -??????? return getNetworkConfig().ip6Addresses() >> -???????????????????????????????? .findFirst() >> -???????????????????????????????? .get(); >> +??????? return networkConfig.ip6Addresses() >> +???????????????????????????? .filter(a -> !a.isLoopbackAddress()) >> +???????????????????????????? .findFirst() >> +???????????????????????????? .orElse(null); >> ????? } >> ? +??? private static NetworkConfiguration networkConfig = >> getNetworkConfig(); >> + >> ????? private static NetworkConfiguration getNetworkConfig() { >> -??????? NetworkConfiguration cfg = null; >> ????????? try { >> -??????????? cfg = NetworkConfiguration.probe(); >> +??????????? return? NetworkConfiguration.probe(); >> ????????? } catch (IOException e) { >> ????????????? System.out.println("Failed to probe >> NetworkConfiguration"); >> ????????????? throw new RuntimeException(e); >> ????????? } >> -??????? return cfg; >> ????? } >> ? -Chris. > From felix.yang at oracle.com Wed Apr 18 06:23:00 2018 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 18 Apr 2018 14:23:00 +0800 Subject: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/* In-Reply-To: References: <201e30e4-7261-482c-cae1-e2cc97028488@oracle.com> Message-ID: <8f57e9a3-33a5-12cb-fea1-a0ec92506c88@oracle.com> On 2018/4/18 14:07, vyom tewari wrote: > Hi Felix, > > latest code looks good to me, personally i prefer to throw exception > instead returning null, but i can see that old code was also returning > null. Yes, that was initial version, but it will make the test failing on host without IPv6 configured. With null, those tests just quit. -Felix > Hopping the code which invokes getFirstLocalIPv4Address, > getFirstLocalIPv6Addres already taken care of null. > > Thanks, > > Vyom > > > On Wednesday 18 April 2018 11:05 AM, Felix Yang wrote: >> Hi Chris and Wyom, >> >> ??? fixed as commented.? Updated webrev: >> >> ??? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.01/ >> >> Thanks, >> Felix >> On 2018/4/17 16:25, Chris Hegarty wrote: >>>> On 17 Apr 2018, at 04:34, Felix Yang wrote: >>>> ... >>>> ???? http://cr.openjdk.java.net/~xiaofeya/8194260/webrev.00/ >>> Thanks for doing this Felix. Mainly looks good. Just a few comments. >>> >>> The old test runs on systems without IPv4 or IPv6 configured. So >>> I think the Optional `get` should be replaced with `orElse`. Either >>> that >>> or update usage to check for the presence of a value in the Optional. >>> >>> The old test filters out the loopback address, in order to get ?real? >>> addresses. I think we should preserve this behaviour. Other filtering >>> is done in the old tests too, but I don?t think it is really needed. >>> >>> --- >>> diff --git a/test/jdk/java/net/ipv6tests/Tests.java >>> b/test/jdk/java/net/ipv6tests/Tests.java >>> --- a/test/jdk/java/net/ipv6tests/Tests.java >>> +++ b/test/jdk/java/net/ipv6tests/Tests.java >>> @@ -178,26 +178,28 @@ >>> ????? } >>> ? ????? public static Inet4Address getFirstLocalIPv4Address () { >>> -??????? return getNetworkConfig().ip4Addresses() >>> -???????????????????????????????? .findFirst() >>> -???????????????????????????????? .get(); >>> +??????? return networkConfig.ip4Addresses() >>> +???????????????????????????? .filter(a -> !a.isLoopbackAddress()) >>> +???????????????????????????? .findFirst() >>> +???????????????????????????? .orElse(null); >>> ????? } >>> ? ????? public static Inet6Address getFirstLocalIPv6Address () { >>> -??????? return getNetworkConfig().ip6Addresses() >>> -???????????????????????????????? .findFirst() >>> -???????????????????????????????? .get(); >>> +??????? return networkConfig.ip6Addresses() >>> +???????????????????????????? .filter(a -> !a.isLoopbackAddress()) >>> +???????????????????????????? .findFirst() >>> +???????????????????????????? .orElse(null); >>> ????? } >>> ? +??? private static NetworkConfiguration networkConfig = >>> getNetworkConfig(); >>> + >>> ????? private static NetworkConfiguration getNetworkConfig() { >>> -??????? NetworkConfiguration cfg = null; >>> ????????? try { >>> -??????????? cfg = NetworkConfiguration.probe(); >>> +??????????? return? NetworkConfiguration.probe(); >>> ????????? } catch (IOException e) { >>> ????????????? System.out.println("Failed to probe >>> NetworkConfiguration"); >>> ????????????? throw new RuntimeException(e); >>> ????????? } >>> -??????? return cfg; >>> ????? } >>> ? -Chris. >> > From christoph.langer at sap.com Wed Apr 18 13:44:44 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Apr 2018 13:44:44 +0000 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: Message-ID: <9d8dd52e4eb7442c81a511b6654498bc@sap.com> Hi Chris, our testing didn?t show regressions. Are we good to push? Best regards Christoph From: Chris Hegarty [mailto:chris.hegarty at oracle.com] Sent: Montag, 16. April 2018 16:39 To: Langer, Christoph Cc: Srividya Shamaiah ; OpenJDK Network Dev list Subject: Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only On 16 Apr 2018, at 10:29, Langer, Christoph > wrote: Hi Srividya, thanks for doing this work. Change looks good from my side, except for a small indentation flaw in lines 91 and 94 and the copyright year that needs to be adjusted. But I can fix this when I push it. +1 Let?s wait for another review (Chris) before we can push it. I?ll also do some testing. I?ll run some tests with this patch too. I?ll also take care of the backport after the push to jdk11. Yes. Let?s first push this to jdk/jdk, then follow up with a back port request as appropriate. -Chris. Best regards Christoph From: Srividya Shamaiah [mailto:sshamaia at in.ibm.com] Sent: Montag, 16. April 2018 10:44 To: Langer, Christoph > Cc: Chris Hegarty >; OpenJDK Network Dev list > Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only Hi Chris, Please review the attached patch in http://cr.openjdk.java.net/~mhorie/8201369/webrev/ Can you also backport this to JDK 8, we have customers waiting for this fix at JDK 8 level. Thanks, Srividya S Srividya Shamaiah---11/04/2018 03:35:38 PM---Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, From: Srividya Shamaiah/India/IBM To: "Langer, Christoph" > Cc: Chris Hegarty >, OpenJDK Network Dev list > Date: 11/04/2018 03:35 PM Subject: RE: 8169865 : Changes not ported to IPv4 ________________________________ Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, Srividya S "Langer, Christoph" ---11/04/2018 02:51:51 PM---Hi Srividya, I would also welcome this fix. From: "Langer, Christoph" > To: Srividya Shamaiah >, Chris Hegarty > Cc: OpenJDK Network Dev list > Date: 11/04/2018 02:51 PM Subject: RE: 8169865 : Changes not ported to IPv4 ________________________________ Hi Srividya, I would also welcome this fix. Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Srividya Shamaiah Sent: Mittwoch, 11. April 2018 09:19 To: Chris Hegarty > Cc: OpenJDK Network Dev list > Subject: Re: 8169865 : Changes not ported to IPv4 Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > From: Chris Hegarty > To: Srividya Shamaiah > Cc: OpenJDK Network Dev list > Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 ________________________________ > On 10 Apr 2018, at 12:34, Srividya Shamaiah > wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved through the bug fix 8169865 which was include at 8u152 level. We were looking this issue from AIX perspective as it did not do the reverse lookup with bug fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 for AIX and linux platforms so that IPv4 and IPv6 processing is consistent for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Apr 18 14:14:31 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 18 Apr 2018 15:14:31 +0100 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: Vyom, On 13/04/18 10:50, vyom tewari wrote: > Hi All, > > Please review the below code. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8194298 > > webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html Here is some proposed wording for the JDK-specific extended socket options specification. 1) Uses a consistent style across all three new options, and is in line with existing extended options. 2) Renamed the options slightly, to improve readability ( they don't need to conform to the native option names ) 3) Reordered them so the build up is more logical 4) Removed inheritance from server sockets 5) Added standard verbiage about being "platform and system dependent 6) Added typical values. I think this is useful, as it gives an idea to the developer, but maybe it could be misleading. Can be dropped if there are concerns. Can you please confirm that this is accurate, and also will leave enough "wriggle" room when additional platform support is added. --- /** * Keep-Alive idle time. * *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE * SO_KEEPALIVE} option is enabled, TCP probes a connection that has been * idle for some amount of time. The default value for this idle period is * system dependent, but is typically 2 hours. The {@code TCP_KEEPIDLE} * option can be used to affect this value for a given socket. * *

The value of this socket option is an {@code Integer} that is the * number of seconds of idle time before keep-alive initiates a probe. The * socket option is specific to stream-oriented sockets using the TCP/IP * protocol. The exact semantics of this socket option are socket type and * system dependent. * * @since 11 */ public static final SocketOption TCP_KEEPIDLE = new ExtSocketOption("TCP_KEEPIDLE", Integer.class); /** * Keep-Alive retransmission interval time. * *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE * SO_KEEPALIVE} option is enabled, TCP probes a connection that has been * idle for some amount of time. If the remote system does not respond to a * keep-alive probe, TCP retransmits the probe after some amount of time. * The default value for this retransmition interval is system dependent, * but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} option can be * used to affect this value for a given socket. * *

The value of this socket option is an {@code Integer} that is the * number of seconds to wait before retransmitting a keep-alive probe. The * socket option is specific to stream-oriented sockets using the TCP/IP * protocol. The exact semantics of this socket option are socket type and * system dependent. * * @since 11 */ public static final SocketOption TCP_KEEPINTERVAL = new ExtSocketOption("TCP_KEEPINTERVAL", Integer.class); /** * Keep-Alive retransmission maximum limit. * *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE * SO_KEEPALIVE} option is enabled, TCP probes a connection that has been * idle for some amount of time. If the remote system does not respond to a * keep-alive probe, TCP retransmits the probe a certain number of times * before a connection is considered to be broken. The default value for * this keep-alive probe retransmit limit is system dependent, but is * typically 8. The {@code TCP_KEEPCOUNT} option can be used to affect * this value for a given socket. * *

The value of this socket option is an {@code Integer} that is the * maximum number of keep-alive probes to be sent. The socket option is * specific to stream-oriented sockets using the TCP/IP protocol. The exact * semantics of this socket option are socket type and system dependent. * * @since 11 */ public static final SocketOption TCP_KEEPCOUNT = new ExtSocketOption("TCP_KEEPCOUNT", Integer.class); -Chris. From chris.hegarty at oracle.com Wed Apr 18 14:19:38 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 18 Apr 2018 15:19:38 +0100 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: <9d8dd52e4eb7442c81a511b6654498bc@sap.com> References: <9d8dd52e4eb7442c81a511b6654498bc@sap.com> Message-ID: Christophe, On 18/04/18 14:44, Langer, Christoph wrote: > Hi Chris, > > our testing didn?t show regressions. Are we good to push? My testing was positive too. I am happy to see this pushed to jdk/jdk. -Chris. From christoph.langer at sap.com Wed Apr 18 14:50:26 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Apr 2018 14:50:26 +0000 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: <9d8dd52e4eb7442c81a511b6654498bc@sap.com> Message-ID: Thank you. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/a838e3707f3a > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 18. April 2018 16:20 > To: Langer, Christoph > Cc: Srividya Shamaiah ; OpenJDK Network Dev list > > Subject: Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse > lookup on Solaris only > > Christophe, > > On 18/04/18 14:44, Langer, Christoph wrote: > > Hi Chris, > > > > our testing didn?t show regressions. Are we good to push? > > My testing was positive too. > > I am happy to see this pushed to jdk/jdk. > > -Chris. From vyom.tewari at oracle.com Wed Apr 18 15:01:29 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Wed, 18 Apr 2018 20:31:29 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: Hi Chris, On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: > Vyom, > > On 13/04/18 10:50, vyom tewari wrote: >> Hi All, >> >> Please review the below code. >> >> BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 >> >> webrev : >> http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > > Here is some proposed wording for the JDK-specific extended socket > options specification. > > 1) Uses a consistent style across all three new options, > ?? and is in line with existing extended options. > 2) Renamed the options slightly, to improve readability > ?? ( they don't need to conform to the native option names ) > 3) Reordered them so the build up is more logical > 4) Removed inheritance from server sockets > 5) Added standard verbiage about being "platform and > ?? system dependent > 6) Added typical values. I think this is useful, as it > ?? gives an idea to the developer, but maybe it could be > ?? misleading. Can be dropped if there are concerns. > > Can you please confirm that this is accurate, and also > will leave enough "wriggle" room when additional platform > support is added. > yes, below is perfect i will do the changes and send the updated webrev soon. Thanks for help, writing Java doc is always harder(4x) than writing code. Vyom > --- > > ??? /** > ???? * Keep-Alive idle time. > ???? * > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > has been > ???? * idle for some amount of time. The default value for this idle > period is > ???? * system dependent, but is typically 2 hours. The {@code > TCP_KEEPIDLE} > ???? * option can be used to affect this value for a given socket. > ???? * > ???? *

The value of this socket option is an {@code Integer} that > is the > ???? * number of seconds of idle time before keep-alive initiates a > probe. The > ???? * socket option is specific to stream-oriented sockets using the > TCP/IP > ???? * protocol. The exact semantics of this socket option are socket > type and > ???? * system dependent. > ???? * > ???? *? @since 11 > ???? */ > ??? public static final SocketOption TCP_KEEPIDLE > ??????????? = new ExtSocketOption("TCP_KEEPIDLE", > Integer.class); > > ??? /** > ???? * Keep-Alive retransmission interval time. > ???? * > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > has been > ???? * idle for some amount of time. If the remote system does not > respond to a > ???? * keep-alive probe, TCP retransmits the probe after some amount > of time. > ???? * The default value for this retransmition interval is system > dependent, > ???? * but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} > option can be > ???? * used to affect this value for a given socket. > ???? * > ???? *

The value of this socket option is an {@code Integer} that > is the > ???? * number of seconds to wait before retransmitting a keep-alive > probe. The > ???? * socket option is specific to stream-oriented sockets using the > TCP/IP > ???? * protocol. The exact semantics of this socket option are socket > type and > ???? * system dependent. > ???? * > ???? * @since 11 > ???? */ > ??? public static final SocketOption TCP_KEEPINTERVAL > ??????????? = new ExtSocketOption("TCP_KEEPINTERVAL", > Integer.class); > > ??? /** > ???? * Keep-Alive retransmission maximum limit. > ???? * > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > has been > ???? * idle for some amount of time. If the remote system does not > respond to a > ???? * keep-alive probe, TCP retransmits the probe a certain number of > times > ???? * before a connection is considered to be broken. The default > value for > ???? * this keep-alive probe retransmit limit is system dependent, but is > ???? * typically 8. The {@code TCP_KEEPCOUNT} option can be used to > affect > ???? * this value for a given socket. > ???? * > ???? *

The value of this socket option is an {@code Integer} that > is the > ???? * maximum number of keep-alive probes to be sent. The socket > option is > ???? * specific to stream-oriented sockets using the TCP/IP protocol. > The exact > ???? * semantics of this socket option are socket type and system > dependent. > ???? * > ???? * @since 11 > ???? */ > ??? public static final SocketOption TCP_KEEPCOUNT > ??????????? = new ExtSocketOption("TCP_KEEPCOUNT", > Integer.class); > > -Chris. From chris.hegarty at oracle.com Wed Apr 18 16:06:44 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 18 Apr 2018 17:06:44 +0100 Subject: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] In-Reply-To: References: Message-ID: <2b58cce0-ec05-ec78-903b-20b55b889885@oracle.com> Ivan, On 16/04/18 17:29, Ivan Gerasimov wrote: > ... > WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/00/webrev/ I think this is mostly good. Just one comment. I'm not sure that this is correct. --- OLD --- 60 String exclBindProp = AccessController.doPrivileged( 61 new GetPropertyAction("sun.net.useExclusiveBind", "")); 62 exclusiveBind = (exclBindProp.isEmpty()) 63 ? true 64 : Boolean.parseBoolean(exclBindProp); --- NEW --- private static final boolean useExclusiveBind = 55 Boolean.parseBoolean(AccessController.doPrivileged( 56 new GetPropertyAction("sun.net.useExclusiveBind", "true"))); Exclusive bind should be true iif: 1) it is defined and has no value, or 2) if is defined and has a value of `true`. I thought we had tests for this, but maybe not if you are not seeing test failures. -Chris. From sshamaia at in.ibm.com Thu Apr 19 06:12:14 2018 From: sshamaia at in.ibm.com (Srividya Shamaiah) Date: Thu, 19 Apr 2018 11:42:14 +0530 Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: References: <9d8dd52e4eb7442c81a511b6654498bc@sap.com> Message-ID: Thanks Chris and Christoph for your help inpushing this to jdk repo. Thanks, Srividya S From: "Langer, Christoph" To: Chris Hegarty Cc: Srividya Shamaiah , OpenJDK Network Dev list Date: 18/04/2018 08:28 PM Subject: RE: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only Thank you. Pushed: https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_a838e3707f3a&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=mg7HJqf6pBG__iOM3R1wpwOwl--BIza3SSbiETJZha8&s=m5KeejbhNWszcJHVMRC5bi01XYsQbRF7gDF8xs1pnOo&e= > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 18. April 2018 16:20 > To: Langer, Christoph > Cc: Srividya Shamaiah ; OpenJDK Network Dev list > > Subject: Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse > lookup on Solaris only > > Christophe, > > On 18/04/18 14:44, Langer, Christoph wrote: > > Hi Chris, > > > > our testing didn?t show regressions. Are we good to push? > > My testing was positive too. > > I am happy to see this pushed to jdk/jdk. > > -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From ivan.gerasimov at oracle.com Thu Apr 19 08:44:36 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 19 Apr 2018 01:44:36 -0700 Subject: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] In-Reply-To: <2b58cce0-ec05-ec78-903b-20b55b889885@oracle.com> References: <2b58cce0-ec05-ec78-903b-20b55b889885@oracle.com> Message-ID: <3a5447bb-3514-17ad-28cf-273fb3424883@oracle.com> Thanks you Chris for reviewing this! On 4/18/18 9:06 AM, Chris Hegarty wrote: > Ivan, > > On 16/04/18 17:29, Ivan Gerasimov wrote: >> ... >> WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/00/webrev/ > > I think this is mostly good. Just one comment. > > > I'm not sure that this is correct. > > --- OLD --- > > 60 String exclBindProp = AccessController.doPrivileged( > 61 new GetPropertyAction("sun.net.useExclusiveBind", > "")); > 62 exclusiveBind = (exclBindProp.isEmpty()) > 63 ? true > 64 : Boolean.parseBoolean(exclBindProp); > > --- NEW --- > private static final boolean useExclusiveBind = > 55 Boolean.parseBoolean(AccessController.doPrivileged( > 56 new GetPropertyAction("sun.net.useExclusiveBind", > "true"))); > > Exclusive bind should be true iif: > 1) it is defined and has no value, or > 2) if is defined and has a value of `true`. > Oh. Good catch! Thanks! I restored the logic here in the updated webrev. > I thought we had tests for this, but maybe not if you are not > seeing test failures. > I found only two tests that set useExclusiveBind. They seem to ignore false positive results, that's why they didn't fail. I updated them to test with useExclusiveBind set either to 'true' or to the empty value. Here's the updated webrev: WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/01/webrev/ With kind regards, Ivan > -Chris. > -- With kind regards, Ivan Gerasimov From chris.hegarty at oracle.com Thu Apr 19 08:50:37 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Apr 2018 09:50:37 +0100 Subject: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] In-Reply-To: <3a5447bb-3514-17ad-28cf-273fb3424883@oracle.com> References: <2b58cce0-ec05-ec78-903b-20b55b889885@oracle.com> <3a5447bb-3514-17ad-28cf-273fb3424883@oracle.com> Message-ID: <827BEB67-836C-412B-BBCB-59AC7B8E2D29@oracle.com> > On 19 Apr 2018, at 09:44, Ivan Gerasimov wrote: > > ... > > WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/01/webrev/ Thanks Ivan. This looks good, and thanks for updating the existing tests to cover the property values ( you know that jtreg now supports spanning @run tags over multiple lines, e.g. [*] ;-) ) -Chris. [*] http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/net/httpclient/BasicRedirectTest.java#l36 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Thu Apr 19 09:12:22 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 19 Apr 2018 02:12:22 -0700 Subject: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] In-Reply-To: <827BEB67-836C-412B-BBCB-59AC7B8E2D29@oracle.com> References: <2b58cce0-ec05-ec78-903b-20b55b889885@oracle.com> <3a5447bb-3514-17ad-28cf-273fb3424883@oracle.com> <827BEB67-836C-412B-BBCB-59AC7B8E2D29@oracle.com> Message-ID: <266349ee-eef9-978e-2f79-8f4cc92bb52f@oracle.com> Thanks again Chris! On 4/19/18 1:50 AM, Chris Hegarty wrote: > >> On 19 Apr 2018, at 09:44, Ivan Gerasimov > > wrote: >> >> ... >> >> WEBREV:http://cr.openjdk.java.net/~igerasim/8201510/01/webrev/ >> > > Thanks Ivan. This looks good, and thanks for updating the existing > tests to cover the property values ( you know that jtreg now supports > spanning @run tags over multiple lines, e.g. [*] ;-) ) > Okay, good to know! I'll break up the long @run lines before pushing. With kind regards, Ivan > -Chris. > > [*] > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/net/httpclient/BasicRedirectTest.java#l36 -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Apr 19 09:20:47 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Apr 2018 10:20:47 +0100 Subject: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] In-Reply-To: <266349ee-eef9-978e-2f79-8f4cc92bb52f@oracle.com> References: <2b58cce0-ec05-ec78-903b-20b55b889885@oracle.com> <3a5447bb-3514-17ad-28cf-273fb3424883@oracle.com> <827BEB67-836C-412B-BBCB-59AC7B8E2D29@oracle.com> <266349ee-eef9-978e-2f79-8f4cc92bb52f@oracle.com> Message-ID: <504AC16C-A278-4BB4-A0EF-6F839D455C80@oracle.com> > On 19 Apr 2018, at 10:12, Ivan Gerasimov wrote: > > Thanks again Chris! > No, thank you. This is a nice simplification of the code. Next step, maybe remove DualStackPlainSocketImpl and merge it into PlainSocketImpl? -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Fri Apr 20 10:08:19 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 20 Apr 2018 15:38:19 +0530 Subject: [PATCH] JDK-8201545 Clarify the return value of InetAddress.getByName/getAllName for empty host value Message-ID: <62425ab1-4ca4-fad0-5478-c3174bc8fc82@gmail.com> Hi, The attached patch addresses the issue noted in [1], by updating the javadoc of InetAddress.getByName and InetAddress.getAllByName to clarify that these methods return a loopback address, if the host parameter is an empty string (same behaviour as host == null). The patch also updates an existing test case to test these methods for both null and empty parameter values. After looking at existing tests for InetAddress, I felt the existing GetLoopbackAddress.java test case is closest to what we are testing here. One thing I need input on, for the GetLoopbackAddress.java test class, is the value of @summary. Should I update it to include a summary of this new test too, or should I remove it altogether? I have anyway updated the @bug to include the JIRA id of this issue. I am open to creating a fresh new test case class just for this issue, if that's better. [1] https://bugs.openjdk.java.net/browse/JDK-8201545 -Jaikiran -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1524215697 -19800 # Fri Apr 20 14:44:57 2018 +0530 # Node ID fbafd0fdcb0033f7d6b65b5686b26e8f23a46c5b # Parent dd5db907ab7e09c87b4dd246f960d97e33fe9c7a JDK-8201545 Clarify the return value of InetAddress#getByName/getAllByName for empty host value diff --git a/src/java.base/share/classes/java/net/InetAddress.java b/src/java.base/share/classes/java/net/InetAddress.java --- a/src/java.base/share/classes/java/net/InetAddress.java +++ b/src/java.base/share/classes/java/net/InetAddress.java @@ -1222,8 +1222,9 @@ * supported. See here for a description of IPv6 * scoped addresses. * - *

If the host is {@code null} then an {@code InetAddress} - * representing an address of the loopback interface is returned. + *

If the host is {@code null} or {@code host.length()} is equal to zero, + * then an {@code InetAddress} representing an address of the + * loopback interface is returned. * See RFC 3330 * section 2 and RFC 2373 * section 2.5.3.

@@ -1262,8 +1263,9 @@ * also be qualified by appending a scoped zone identifier or scope_id. * The syntax and usage of scope_ids is described * here. - *

If the host is {@code null} then an {@code InetAddress} - * representing an address of the loopback interface is returned. + *

If the host is {@code null} or {@code host.length()} is equal to zero, + * then an {@code InetAddress} representing an address of the + * loopback interface is returned. * See RFC 3330 * section 2 and RFC 2373 * section 2.5.3.

diff --git a/test/jdk/java/net/InetAddress/GetLoopbackAddress.java b/test/jdk/java/net/InetAddress/GetLoopbackAddress.java --- a/test/jdk/java/net/InetAddress/GetLoopbackAddress.java +++ b/test/jdk/java/net/InetAddress/GetLoopbackAddress.java @@ -23,7 +23,7 @@ /** * @test - * @bug 6376404 + * @bug 6376404 8201545 * @summary InetAddress needs a getLoopbackAddress */ import java.net.*; @@ -45,17 +45,41 @@ } } - public static void main(String[] args) { + public static void main(String[] args) throws Exception { InetAddress addr = InetAddress.getLoopbackAddress(); - if (!(addr.equals(IPv4Loopback) || addr.equals(IPv6Loopback))) + if (!(addr.equals(IPv4Loopback) || addr.equals(IPv6Loopback))) { throw new RuntimeException("Failed: getLoopbackAddress" + " not returning a valid loopback address"); + } InetAddress addr2 = InetAddress.getLoopbackAddress(); - if (addr != addr2) + if (addr != addr2) { throw new RuntimeException("Failed: getLoopbackAddress" + " should return a reference to the same InetAddress loopback instance."); + } + + InetAddress addrFromNullHost = InetAddress.getByName(null); + if (!addrFromNullHost.isLoopbackAddress()) { + throw new RuntimeException("getByName(null) did not return a" + + " loopback address"); + } + InetAddress addrFromEmptyHost = InetAddress.getByName(""); + if (!addrFromEmptyHost.isLoopbackAddress()) { + throw new RuntimeException("getByName with a host of length == 0," + + " did not return a loopback address"); + } + + InetAddress[] adrsByNull = InetAddress.getAllByName(null); + if (!adrsByNull[0].isLoopbackAddress()) { + throw new RuntimeException("getAllByName(null) did not return" + + " a loopback address"); + } + InetAddress[] adrsByEmpty = InetAddress.getAllByName(""); + if (!adrsByEmpty[0].isLoopbackAddress()) { + throw new RuntimeException("getAllByName with a host of length" + + " == 0, did not return a loopback address"); + } } } From ivan.gerasimov at oracle.com Fri Apr 20 20:32:58 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Apr 2018 13:32:58 -0700 Subject: RFR 8202091 : Rename DualStackPlainSocketImpl to PlainSocketImpl [win] Message-ID: <4577d9c0-afb0-1dcc-e4f3-707f0bf685c1@oracle.com> Hello! After integrating the fix for JDK-8201510, there is only one implementation of PlainSocketImpl left on Windows. It is proposed to just rename DualStackPlainSocketImpl to PlainSocketImpl and avoid the indirection. Some minor cleanup was done with this change: - dropping static PlainSocketImpl.isReusePortAvailable() -- it wasn't called anyway and just hid the same named function in the super class, - minor re-formatting. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8194534 WEBREV: http://javaweb.us.oracle.com/~igerasim/webrevs/8194534/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Fri Apr 20 20:40:02 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Apr 2018 13:40:02 -0700 Subject: RFR 8202091 : Rename DualStackPlainSocketImpl to PlainSocketImpl [win] In-Reply-To: <4577d9c0-afb0-1dcc-e4f3-707f0bf685c1@oracle.com> References: <4577d9c0-afb0-1dcc-e4f3-707f0bf685c1@oracle.com> Message-ID: <6586f7ac-7aec-c6e6-0399-4fc7703ee34e@oracle.com> The correct links to the Bug and webrev are: BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202091 WEBREV: http://cr.openjdk.java.net/~igerasim/8202091/00/webrev/ Sorry for confusion! With kind regards, Ivan On 4/20/18 1:32 PM, Ivan Gerasimov wrote: > Hello! > > After integrating the fix for JDK-8201510, there is only one > implementation of PlainSocketImpl left on Windows. > > It is proposed to just rename DualStackPlainSocketImpl to > PlainSocketImpl and avoid the indirection. > > Some minor cleanup was done with this change: > - dropping static PlainSocketImpl.isReusePortAvailable() -- it wasn't > called anyway and just hid the same named function in the super class, > - minor re-formatting. > > Would you please help review the fix? > > Thanks in advance! > -- With kind regards, Ivan Gerasimov From peter.gergely.horvath at gmail.com Sun Apr 22 19:59:14 2018 From: peter.gergely.horvath at gmail.com (=?UTF-8?Q?P=C3=A9ter_Gergely_Horv=C3=A1th?=) Date: Sun, 22 Apr 2018 21:59:14 +0200 Subject: java.net.Socket should report the attempted address and port Message-ID: Hi All, I am wondering if it would be possible to make a minor improvement to the way *java.net.Socket* reports connectivity errors and incorporate the attempted address, port and the timeout used into the exception message. The current implementation emits a generic error message, which is not that helpful when one is operating a _large_ application. (Consider e.g. Big Data or complex legacy systems written by someone else). java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at java.net.Socket.connect(Socket.java:538) at java.net.Socket.(Socket.java:434) at java.net.Socket.(Socket.java:211) at Sample.main(Sample.java:9) I have looked into the JDK code base and implemented a patch that reports the address, port and timeout used in the error message without touching any native parts (see attached patch file). I have tested this (created my own build of the JDK and run a sample application against it) and it seems to work properly. Would it be possible to incorporate this change into the official JDK code base? I do believe it would help a lot of people out there. Based on my understanding, once I have signed the OCA, I should simply write an email to the group and request a sponsor to pick up this issue. Could someone help me with this? Thank you, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: socket.patch Type: application/octet-stream Size: 2159 bytes Desc: not available URL: From tobiast at google.com Sun Apr 22 20:11:20 2018 From: tobiast at google.com (Tobias Thierer) Date: Sun, 22 Apr 2018 20:11:20 +0000 Subject: java.net.Socket should report the attempted address and port In-Reply-To: References: Message-ID: There was a similar discussion recently: http://mail.openjdk.java.net/pipermail/net-dev/2017-December/011097.html On Sun, 22 Apr 2018, 20:59 P?ter Gergely Horv?th, < peter.gergely.horvath at gmail.com> wrote: > Hi All, > > I am wondering if it would be possible to make a minor improvement to the > way *java.net.Socket* reports connectivity errors and incorporate the > attempted address, port and the timeout used into the exception message. > > The current implementation emits a generic error message, which is not > that helpful when one is operating a _large_ application. (Consider e.g. > Big Data or complex legacy systems written by someone else). > > java.net.ConnectException: Connection refused (Connection refused) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at java.net.Socket.(Socket.java:434) > at java.net.Socket.(Socket.java:211) > at Sample.main(Sample.java:9) > > > I have looked into the JDK code base and implemented a patch that reports > the address, port and timeout used in the error message without touching > any native parts (see attached patch file). I have tested this (created my > own build of the JDK and run a sample application against it) and it seems > to work properly. > > Would it be possible to incorporate this change into the official JDK code > base? I do believe it would help a lot of people out there. > > Based on my understanding, once I have signed the OCA, I should simply > write an email to the group and request a sponsor to pick up this issue. > Could someone help me with this? > > Thank you, > Peter > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at lightbend.com Sun Apr 22 20:21:24 2018 From: james at lightbend.com (James Roper) Date: Sun, 22 Apr 2018 21:21:24 +0100 Subject: java.net.Socket should report the attempted address and port In-Reply-To: References: Message-ID: This would be especially useful in asynchronous applications - since in those cases the exception rarely maps back to a place in user code that would indicate what is being connected to. As someone who has spent a lot of time supporting developers who use asynchronous libraries and post exceptions of this nature (supporting both in open source, eg on stack overflow, as well as providing commercial support), where I don't have access to their code base so I can't do the necessary investigations directly myself, having the attempted address and port in the error message would save a lot of time, and probably even prevent a lot of people from requiring support in the first place. On 22 April 2018 at 20:59, P?ter Gergely Horv?th < peter.gergely.horvath at gmail.com> wrote: > Hi All, > > I am wondering if it would be possible to make a minor improvement to the > way *java.net.Socket* reports connectivity errors and incorporate the > attempted address, port and the timeout used into the exception message. > > The current implementation emits a generic error message, which is not > that helpful when one is operating a _large_ application. (Consider e.g. > Big Data or complex legacy systems written by someone else). > > java.net.ConnectException: Connection refused (Connection refused) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.AbstractPlainSocketImpl.doConnect( > AbstractPlainSocketImpl.java:350) > at java.net.AbstractPlainSocketImpl.connectToAddress( > AbstractPlainSocketImpl.java:206) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java: > 188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at java.net.Socket.(Socket.java:434) > at java.net.Socket.(Socket.java:211) > at Sample.main(Sample.java:9) > > > I have looked into the JDK code base and implemented a patch that reports > the address, port and timeout used in the error message without touching > any native parts (see attached patch file). I have tested this (created my > own build of the JDK and run a sample application against it) and it seems > to work properly. > > Would it be possible to incorporate this change into the official JDK code > base? I do believe it would help a lot of people out there. > > Based on my understanding, once I have signed the OCA, I should simply > write an email to the group and request a sponsor to pick up this issue. > Could someone help me with this? > > Thank you, > Peter > > > > > > > > -- *James Roper* *Senior Octonaut* Lightbend ? Build reactive apps! Twitter: @jroper -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Apr 23 06:38:13 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Apr 2018 06:38:13 +0000 Subject: RFR 8202091 : Rename DualStackPlainSocketImpl to PlainSocketImpl [win] In-Reply-To: <6586f7ac-7aec-c6e6-0399-4fc7703ee34e@oracle.com> References: <4577d9c0-afb0-1dcc-e4f3-707f0bf685c1@oracle.com> <6586f7ac-7aec-c6e6-0399-4fc7703ee34e@oracle.com> Message-ID: Hi Ivan, this looks good to me. Next nice step in cleaning up the socket implementation. Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > Ivan Gerasimov > Sent: Freitag, 20. April 2018 22:40 > To: net-dev at openjdk.java.net > Subject: Re: RFR 8202091 : Rename DualStackPlainSocketImpl to > PlainSocketImpl [win] > > The correct links to the Bug and webrev are: > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202091 > WEBREV: http://cr.openjdk.java.net/~igerasim/8202091/00/webrev/ > > Sorry for confusion! > > With kind regards, > Ivan > > On 4/20/18 1:32 PM, Ivan Gerasimov wrote: > > Hello! > > > > After integrating the fix for JDK-8201510, there is only one > > implementation of PlainSocketImpl left on Windows. > > > > It is proposed to just rename DualStackPlainSocketImpl to > > PlainSocketImpl and avoid the indirection. > > > > Some minor cleanup was done with this change: > > - dropping static PlainSocketImpl.isReusePortAvailable() -- it wasn't > > called anyway and just hid the same named function in the super class, > > - minor re-formatting. > > > > Would you please help review the fix? > > > > Thanks in advance! > > > > -- > With kind regards, > Ivan Gerasimov From peter.gergely.horvath at gmail.com Mon Apr 23 09:05:53 2018 From: peter.gergely.horvath at gmail.com (=?UTF-8?Q?P=C3=A9ter_Gergely_Horv=C3=A1th?=) Date: Mon, 23 Apr 2018 11:05:53 +0200 Subject: java.net.Socket should report the attempted address and port In-Reply-To: References: Message-ID: Hi Tobias, Thank you for pointing me to that thread: it's good to have that context (it was sent before I joined the mailing list, so please bear with me). I understand the JDK developers want to be safe than sorry around reporting target addresses and I absolutely agree with that point. However considering how useful it would be to have this _optionally_ for debugging, I am wondering if it would be possible to have a dedicated Java system property defined for this (e.g. 'java.net.socket.reportAddressInException' or something like that), which would enable this behaviour (retaining the current behaviour of *not reporting anything by default.*). What do you think about this, guys? With this in place both the secure-by-default requirement would be met, and there would be a powerful tool available to fight the horrors of debugging a running complex distributed application from its logs. Thanks, Peter On Sun, Apr 22, 2018 at 10:21 PM, James Roper wrote: > This would be especially useful in asynchronous applications - since in > those cases the exception rarely maps back to a place in user code that > would indicate what is being connected to. As someone who has spent a lot > of time supporting developers who use asynchronous libraries and post > exceptions of this nature (supporting both in open source, eg on stack > overflow, as well as providing commercial support), where I don't have > access to their code base so I can't do the necessary investigations > directly myself, having the attempted address and port in the error message > would save a lot of time, and probably even prevent a lot of people from > requiring support in the first place. > > On 22 April 2018 at 20:59, P?ter Gergely Horv?th < > peter.gergely.horvath at gmail.com> wrote: > >> Hi All, >> >> I am wondering if it would be possible to make a minor improvement to the >> way *java.net.Socket* reports connectivity errors and incorporate the >> attempted address, port and the timeout used into the exception message. >> >> The current implementation emits a generic error message, which is not >> that helpful when one is operating a _large_ application. (Consider e.g. >> Big Data or complex legacy systems written by someone else). >> >> java.net.ConnectException: Connection refused (Connection refused) >> at java.net.PlainSocketImpl.socketConnect(Native Method) >> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock >> etImpl.java:350) >> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl >> ainSocketImpl.java:206) >> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket >> Impl.java:188) >> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) >> at java.net.Socket.connect(Socket.java:589) >> at java.net.Socket.connect(Socket.java:538) >> at java.net.Socket.(Socket.java:434) >> at java.net.Socket.(Socket.java:211) >> at Sample.main(Sample.java:9) >> >> >> I have looked into the JDK code base and implemented a patch that reports >> the address, port and timeout used in the error message without touching >> any native parts (see attached patch file). I have tested this (created my >> own build of the JDK and run a sample application against it) and it seems >> to work properly. >> >> Would it be possible to incorporate this change into the official JDK >> code base? I do believe it would help a lot of people out there. >> >> Based on my understanding, once I have signed the OCA, I should simply >> write an email to the group and request a sponsor to pick up this issue. >> Could someone help me with this? >> >> Thank you, >> Peter >> >> >> >> >> >> >> >> > > > -- > *James Roper* > *Senior Octonaut* > > Lightbend ? Build reactive apps! > Twitter: @jroper > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Apr 23 10:14:42 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Apr 2018 11:14:42 +0100 Subject: RFR 8202091 : Rename DualStackPlainSocketImpl to PlainSocketImpl [win] In-Reply-To: <6586f7ac-7aec-c6e6-0399-4fc7703ee34e@oracle.com> References: <4577d9c0-afb0-1dcc-e4f3-707f0bf685c1@oracle.com> <6586f7ac-7aec-c6e6-0399-4fc7703ee34e@oracle.com> Message-ID: <8a37875f-c48b-c05e-6cef-d61e19d90ed2@oracle.com> On 20/04/18 21:40, Ivan Gerasimov wrote: > The correct links to the Bug and webrev are: > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202091 > WEBREV: http://cr.openjdk.java.net/~igerasim/8202091/00/webrev/ This looks good. Thanks Ivan. -Chris. From chris.hegarty at oracle.com Mon Apr 23 11:33:27 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Apr 2018 12:33:27 +0100 Subject: [PATCH] JDK-8201545 Clarify the return value of InetAddress.getByName/getAllName for empty host value In-Reply-To: <62425ab1-4ca4-fad0-5478-c3174bc8fc82@gmail.com> References: <62425ab1-4ca4-fad0-5478-c3174bc8fc82@gmail.com> Message-ID: <98776495-d3c1-c7c1-fc92-e47785ce86d2@oracle.com> Thanks Jaikiran, I think your patch looks good. I filed the following CSR to track the Java SE API ( javadoc ) change. https://bugs.openjdk.java.net/browse/JDK-8202139 Once approved, I can sponsor this for you. -Chris. On 20/04/18 11:08, Jaikiran Pai wrote: > Hi, > > The attached patch addresses the issue noted in [1], by updating the > javadoc of InetAddress.getByName and InetAddress.getAllByName to clarify > that these methods return a loopback address, if the host parameter is > an empty string (same behaviour as host == null). The patch also updates > an existing test case to test these methods for both null and empty > parameter values. > > After looking at existing tests for InetAddress, I felt the existing > GetLoopbackAddress.java test case is closest to what we are testing > here. One thing I need input on, for the GetLoopbackAddress.java test > class, is the value of @summary. Should I update it to include a summary > of this new test too, or should I remove it altogether? I have anyway > updated the @bug to include the JIRA id of this issue. I am open to > creating a fresh new test case class just for this issue, if that's better. > > [1] https://bugs.openjdk.java.net/browse/JDK-8201545 > > -Jaikiran > From vyom.tewari at oracle.com Mon Apr 23 12:05:33 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Mon, 23 Apr 2018 17:35:33 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). I incorporated? most of the review comments. Thanks, Vyom On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: > Vyom, > > On 13/04/18 10:50, vyom tewari wrote: >> Hi All, >> >> Please review the below code. >> >> BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 >> >> webrev : >> http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > > Here is some proposed wording for the JDK-specific extended socket > options specification. > > 1) Uses a consistent style across all three new options, > ?? and is in line with existing extended options. > 2) Renamed the options slightly, to improve readability > ?? ( they don't need to conform to the native option names ) > 3) Reordered them so the build up is more logical > 4) Removed inheritance from server sockets > 5) Added standard verbiage about being "platform and > ?? system dependent > 6) Added typical values. I think this is useful, as it > ?? gives an idea to the developer, but maybe it could be > ?? misleading. Can be dropped if there are concerns. > > Can you please confirm that this is accurate, and also > will leave enough "wriggle" room when additional platform > support is added. > > --- > > ??? /** > ???? * Keep-Alive idle time. > ???? * > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > has been > ???? * idle for some amount of time. The default value for this idle > period is > ???? * system dependent, but is typically 2 hours. The {@code > TCP_KEEPIDLE} > ???? * option can be used to affect this value for a given socket. > ???? * > ???? *

The value of this socket option is an {@code Integer} that > is the > ???? * number of seconds of idle time before keep-alive initiates a > probe. The > ???? * socket option is specific to stream-oriented sockets using the > TCP/IP > ???? * protocol. The exact semantics of this socket option are socket > type and > ???? * system dependent. > ???? * > ???? *? @since 11 > ???? */ > ??? public static final SocketOption TCP_KEEPIDLE > ??????????? = new ExtSocketOption("TCP_KEEPIDLE", > Integer.class); > > ??? /** > ???? * Keep-Alive retransmission interval time. > ???? * > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > has been > ???? * idle for some amount of time. If the remote system does not > respond to a > ???? * keep-alive probe, TCP retransmits the probe after some amount > of time. > ???? * The default value for this retransmition interval is system > dependent, > ???? * but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} > option can be > ???? * used to affect this value for a given socket. > ???? * > ???? *

The value of this socket option is an {@code Integer} that > is the > ???? * number of seconds to wait before retransmitting a keep-alive > probe. The > ???? * socket option is specific to stream-oriented sockets using the > TCP/IP > ???? * protocol. The exact semantics of this socket option are socket > type and > ???? * system dependent. > ???? * > ???? * @since 11 > ???? */ > ??? public static final SocketOption TCP_KEEPINTERVAL > ??????????? = new ExtSocketOption("TCP_KEEPINTERVAL", > Integer.class); > > ??? /** > ???? * Keep-Alive retransmission maximum limit. > ???? * > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > has been > ???? * idle for some amount of time. If the remote system does not > respond to a > ???? * keep-alive probe, TCP retransmits the probe a certain number of > times > ???? * before a connection is considered to be broken. The default > value for > ???? * this keep-alive probe retransmit limit is system dependent, but is > ???? * typically 8. The {@code TCP_KEEPCOUNT} option can be used to > affect > ???? * this value for a given socket. > ???? * > ???? *

The value of this socket option is an {@code Integer} that > is the > ???? * maximum number of keep-alive probes to be sent. The socket > option is > ???? * specific to stream-oriented sockets using the TCP/IP protocol. > The exact > ???? * semantics of this socket option are socket type and system > dependent. > ???? * > ???? * @since 11 > ???? */ > ??? public static final SocketOption TCP_KEEPCOUNT > ??????????? = new ExtSocketOption("TCP_KEEPCOUNT", > Integer.class); > > -Chris. From Alan.Bateman at oracle.com Mon Apr 23 12:34:51 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Apr 2018 13:34:51 +0100 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: On 23/04/2018 13:05, vyom tewari wrote: > Hi, > > Please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). > I incorporated? most of the review comments. This looks much better but I think the second paragraph of the spec of each option needs to be inverted so that it states clearly what the options does before it gets into the background of SO_KEEPALIVE. For example, TCP_KEEPALIVE should say that it sets the idle period for keep alive before it explains SO_KEEPALIVE. The currently wording also begs questions as to whether the socket option means anything when SO_KEEPALIVE is not enabled. Also it probably should say something about whether it can be changed at any time or not. The implementation looks much better but the filtering by socket option name is still a bit fragile. It might be better for ExtendedSocketOptions to mainain 3 sets of options, one for SOCK_UNSPEC, one for SOCK_STREAM, the other for SOCK_DGRAM. A map would work too. The register method can specify socket type and it's very obvious which sockets the option is intended to be used for. All usages are now ExtendedSocketOptions.getInstance().options(...). Have you considered a static options(...) method to reduce the typing at each of the usage sites? -Alan From christoph.langer at sap.com Mon Apr 23 12:49:39 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Apr 2018 12:49:39 +0000 Subject: [8u] RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only Message-ID: <4b30c8a31200469d8c7e784816230a01@sap.com> Hi, I created a JDK 8 backport proposal for JDK-8201369: http://cr.openjdk.java.net/~clanger/webrevs/8201369-jdk8.0/ This is the Bug: https://bugs.openjdk.java.net/browse/JDK-8201369 The issue was recently discussed and reviewed here: http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011322.html Apart from limiting the getaddrinfo/getnameinfo lookup in Java_java_net_Inet4AddressImpl_getLocalHostName to Solaris only, I took over the formatting cleanups to make both Ipv4 and IPv6 versions look similar and resemble the layout in the current jdk depot. Please help reviewing this for JDK 8. Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Mon Apr 23 13:13:55 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Apr 2018 14:13:55 +0100 Subject: java.net.Socket should report the attempted address and port In-Reply-To: References: Message-ID: <5ADDDC13.7020100@oracle.com> I agree we should do something about this. I will make some enquiries with the security folks here as to what might be permitted. I suspect either some kind of debugging property/switch to enable it, or the limited information only being provided when a security manager is enabled, might work. I will get back with a firm proposal. Thanks, Michael. On 23/04/2018, 10:05, P?ter Gergely Horv?th wrote: > Hi Tobias, > > Thank you for pointing me to that thread: it's good to have that > context (it was sent before I joined the mailing list, so please bear > with me). > > I understand the JDK developers want to be safe than sorry around > reporting target addresses and I absolutely agree with that point. > > However considering how useful it would be to have this _optionally_ > for debugging, I am wondering if it would be possible to have a > dedicated Java system property defined for this (e.g. > 'java.net.socket.reportAddressInException' or something like that), > which would enable this behaviour (retaining the current behaviour of > *not reporting anything by default.*). > > What do you think about this, guys? With this in place both the > secure-by-default requirement would be met, and there would be a > powerful tool available to fight the horrors of debugging a running > complex distributed application from its logs. > > Thanks, > Peter > > > > > > On Sun, Apr 22, 2018 at 10:21 PM, James Roper > wrote: > > This would be especially useful in asynchronous applications - > since in those cases the exception rarely maps back to a place in > user code that would indicate what is being connected to. As > someone who has spent a lot of time supporting developers who use > asynchronous libraries and post exceptions of this nature > (supporting both in open source, eg on stack overflow, as well as > providing commercial support), where I don't have access to their > code base so I can't do the necessary investigations directly > myself, having the attempted address and port in the error message > would save a lot of time, and probably even prevent a lot of > people from requiring support in the first place. > > On 22 April 2018 at 20:59, P?ter Gergely Horv?th > > wrote: > > Hi All, > > I am wondering if it would be possible to make a minor > improvement to the way *java.net.Socket* reports connectivity > errors and incorporate the attempted address, port and the > timeout used into the exception message. > > The current implementation emits a generic error message, > which is not that helpful when one is operating a _large_ > application. (Consider e.g. Big Data or complex legacy systems > written by someone else). > > java.net.ConnectException: Connection refused (Connection refused) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net > .AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at java.net > .AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at java.net > .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at java.net.Socket.(Socket.java:434) > at java.net.Socket.(Socket.java:211) > at Sample.main(Sample.java:9) > > > I have looked into the JDK code base and implemented a patch > that reports the address, port and timeout used in the error > message without touching any native parts (see attached patch > file). I have tested this (created my own build of the JDK and > run a sample application against it) and it seems to work > properly. > > Would it be possible to incorporate this change into the > official JDK code base? I do believe it would help a lot of > people out there. > > Based on my understanding, once I have signed the OCA, I > should simply write an email to the group and request > a sponsor to pick up this issue. Could someone help me with this? > > Thank you, > Peter > > > > > > > > > > > -- > *James Roper* > /Senior Octonaut/ > > Lightbend ? Build reactive apps! > Twitter: @jroper > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Apr 23 13:56:35 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Apr 2018 14:56:35 +0100 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: <5cb96c41-8149-b548-4a78-bf610c3bcaa6@oracle.com> On 23/04/18 13:34, Alan Bateman wrote: > On 23/04/2018 13:05, vyom tewari wrote: >> Hi, >> >> Please find the latest >> webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). >> I incorporated most of the review comments. > This looks much better but I think the second paragraph of the spec of > each option needs to be inverted so that it states clearly what the > options does before it gets into the background of SO_KEEPALIVE. For > example, TCP_KEEPALIVE should say that it sets the idle period for keep > alive before it explains SO_KEEPALIVE. Mea culpa, I ordered the paragraphs as they are to be consistent with TCP_QUICKACK. I don't have any objection if they are reversed. > The currently wording also begs > questions as to whether the socket option means anything when > SO_KEEPALIVE is not enabled. It's implicit. The option can still be set and its value retrieved. > Also it probably should say something about > whether it can be changed at any time or not. You can set it any time. Of course, it may not be effective immediately, depending on the exact state of the socket. We may also want to add a note that the accepted values may have an upper-bound. For example, the following is the largest set of values that I can set on my Ubuntu Linux, without an exception being thrown [*]. TCP_KEEPIDLE = 32767 TCP_KEEPINTERVAL = 32767 TCP_KEEPCOUNT = 127 -Chris. [*] "java.net.SocketException: Invalid argument" when a given value is "too" large. From chris.hegarty at oracle.com Mon Apr 23 13:58:56 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Apr 2018 14:58:56 +0100 Subject: [8u] RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only In-Reply-To: <4b30c8a31200469d8c7e784816230a01@sap.com> References: <4b30c8a31200469d8c7e784816230a01@sap.com> Message-ID: <9816ccfe-af32-e80d-b659-6b9d9ceb10ae@oracle.com> On 23/04/18 13:49, Langer, Christoph wrote: > Hi, > > I created a JDK 8 backport proposal for JDK-8201369: > http://cr.openjdk.java.net/~clanger/webrevs/8201369-jdk8.0/ > > This is the Bug: https://bugs.openjdk.java.net/browse/JDK-8201369 > > The issue was recently discussed and reviewed here: > http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011322.html > > Apart from limiting the getaddrinfo/getnameinfo lookup in > Java_java_net_Inet4AddressImpl_getLocalHostName to Solaris only, I took > over the formatting cleanups to make both Ipv4 and IPv6 versions look > similar and resemble the layout in the current jdk depot. > > Please help reviewing this for JDK 8. The code changes look ok to me. -Chris. From jai.forums2013 at gmail.com Mon Apr 23 14:03:20 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 23 Apr 2018 19:33:20 +0530 Subject: [PATCH] JDK-8201545 Clarify the return value of InetAddress.getByName/getAllName for empty host value In-Reply-To: <98776495-d3c1-c7c1-fc92-e47785ce86d2@oracle.com> References: <62425ab1-4ca4-fad0-5478-c3174bc8fc82@gmail.com> <98776495-d3c1-c7c1-fc92-e47785ce86d2@oracle.com> Message-ID: <9867498b-bb3e-09a7-6131-6bc8ea56f78a@gmail.com> Thank you Chris. -Jaikiran On 23/04/18 5:03 PM, Chris Hegarty wrote: > Thanks Jaikiran, > > I think your patch looks good. I filed the following CSR to track > the Java SE API ( javadoc ) change. > > https://bugs.openjdk.java.net/browse/JDK-8202139 > > Once approved, I can sponsor this for you. > > -Chris. > > On 20/04/18 11:08, Jaikiran Pai wrote: >> Hi, >> >> The attached patch addresses the issue noted in [1], by updating the >> javadoc of InetAddress.getByName and InetAddress.getAllByName to >> clarify that these methods return a loopback address, if the host >> parameter is an empty string (same behaviour as host == null). The >> patch also updates an existing test case to test these methods for >> both null and empty parameter values. >> >> After looking at existing tests for InetAddress, I felt the existing >> GetLoopbackAddress.java test case is closest to what we are testing >> here. One thing I need input on, for the GetLoopbackAddress.java test >> class, is the value of @summary. Should I update it to include a >> summary of this new test too, or should I remove it altogether? I >> have anyway updated the @bug to include the JIRA id of this issue. I >> am open to creating a fresh new test case class just for this issue, >> if that's better. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8201545 >> >> -Jaikiran >> From ivan.gerasimov at oracle.com Mon Apr 23 21:29:14 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 23 Apr 2018 14:29:14 -0700 Subject: RFR 8202154 : Remove unused code in TwoStacksPlainDatagramSocketImpl.c Message-ID: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> Hello! Some code in TwoStacksPlainDatagramSocketImpl.c is only relevant for earlier versions of Windows, which are no longer supported as of JDK 11. This code can be safely removed. Also removing an unused argument at DualStackPlainDatagramSocketImpl.socketCreate(). Would you please help review this cleanup? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154 WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Tue Apr 24 04:17:32 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 23 Apr 2018 21:17:32 -0700 Subject: RFR 8202154 : Remove unused code in java.base/windows/native/libnet In-Reply-To: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> References: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> Message-ID: <0ff6798e-58e0-e26d-1972-289772dd1e9e@oracle.com> Hello again! A few other files contain obsolete code, so they can be combined together in one fix. The webrev was updated in place: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ Here's the summary of additional changes: - sun.net.PortConfig.getLower()/getUpper() always return the same range, so it can be defined with constants, - NET_GetDefaultTOS() always returns zero, so it can be removed. Would you please help review this? With kind regards, Ivan On 4/23/18 2:29 PM, Ivan Gerasimov wrote: > Hello! > > Some code in TwoStacksPlainDatagramSocketImpl.c is only relevant for > earlier versions of Windows, which are no longer supported as of JDK 11. > This code can be safely removed. > > Also removing an unused argument at > DualStackPlainDatagramSocketImpl.socketCreate(). > > Would you please help review this cleanup? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154 > WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ > > Thanks in advance! > -- With kind regards, Ivan Gerasimov From vyom.tewari at oracle.com Tue Apr 24 06:29:15 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 24 Apr 2018 11:59:15 +0530 Subject: RFR 8202154 : Remove unused code in java.base/windows/native/libnet In-Reply-To: <0ff6798e-58e0-e26d-1972-289772dd1e9e@oracle.com> References: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> <0ff6798e-58e0-e26d-1972-289772dd1e9e@oracle.com> Message-ID: <25611d51-96af-a403-73fd-d82bc094dc3d@oracle.com> Hi Ivan, code looks good to me, thanks for doing this cleanup. One minor comment, in PortConfig.java you can make defaultUpper& defaultLower as final.I see that Microsoft changed dynamic port range recently do we need to put some comment in PortConfig.java ? Thanks, Vyom On Tuesday 24 April 2018 09:47 AM, Ivan Gerasimov wrote: > Hello again! > > A few other files contain obsolete code, so they can be combined > together in one fix. > > The webrev was updated in place: > http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ > > Here's the summary of additional changes: > - sun.net.PortConfig.getLower()/getUpper() always return the same > range, so it can be defined with constants, > - NET_GetDefaultTOS() always returns zero, so it can be removed. > > Would you please help review this? > > With kind regards, > Ivan > > On 4/23/18 2:29 PM, Ivan Gerasimov wrote: >> Hello! >> >> Some code in TwoStacksPlainDatagramSocketImpl.c is only relevant for >> earlier versions of Windows, which are no longer supported as of JDK 11. >> This code can be safely removed. >> >> Also removing an unused argument at >> DualStackPlainDatagramSocketImpl.socketCreate(). >> >> Would you please help review this cleanup? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ >> >> Thanks in advance! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Apr 24 07:32:27 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Apr 2018 07:32:27 +0000 Subject: RFR 8202154 : Remove unused code in java.base/windows/native/libnet In-Reply-To: <25611d51-96af-a403-73fd-d82bc094dc3d@oracle.com> References: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> <0ff6798e-58e0-e26d-1972-289772dd1e9e@oracle.com> <25611d51-96af-a403-73fd-d82bc094dc3d@oracle.com> Message-ID: <57838d49ed924bf9aa85e3fc2bda9601@sap.com> Hi Ivan, looks good. I agree that the fields that Vyom mentioned should be final. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of vyom tewari Sent: Dienstag, 24. April 2018 08:29 To: net-dev at openjdk.java.net Subject: Re: RFR 8202154 : Remove unused code in java.base/windows/native/libnet Hi Ivan, code looks good to me, thanks for doing this cleanup. One minor comment, in PortConfig.java you can make defaultUpper& defaultLower as final.I see that Microsoft changed dynamic port range recently do we need to put some comment in PortConfig.java ? Thanks, Vyom On Tuesday 24 April 2018 09:47 AM, Ivan Gerasimov wrote: Hello again! A few other files contain obsolete code, so they can be combined together in one fix. The webrev was updated in place: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ Here's the summary of additional changes: - sun.net.PortConfig.getLower()/getUpper() always return the same range, so it can be defined with constants, - NET_GetDefaultTOS() always returns zero, so it can be removed. Would you please help review this? With kind regards, Ivan On 4/23/18 2:29 PM, Ivan Gerasimov wrote: Hello! Some code in TwoStacksPlainDatagramSocketImpl.c is only relevant for earlier versions of Windows, which are no longer supported as of JDK 11. This code can be safely removed. Also removing an unused argument at DualStackPlainDatagramSocketImpl.socketCreate(). Would you please help review this cleanup? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154 WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Apr 24 09:38:55 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Apr 2018 09:38:55 +0000 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations Message-ID: Hi, please help reviewing a small change that I stumbled over when looking into the getLocalHostName implementation. I found that the length of the hostname buffer is not correctly passed to sub functions. The buffer size is specified as "NI_MAXHOST + 1", so this size should be handed down to gethostname() and getnameinfo() calls, not just NI_MAXHOST. I also moved the solaris #ifdefs into the else clause to spare a few lines of code. Bug: https://bugs.openjdk.java.net/browse/JDK-8202181 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202181.0/ Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Tue Apr 24 10:24:31 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 24 Apr 2018 15:54:31 +0530 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: Message-ID: On Tuesday 24 April 2018 03:08 PM, Langer, Christoph wrote: > > Hi, > > please help reviewing a small change that I stumbled over when looking > into the getLocalHostName implementation. I found that the length of > the hostname buffer is not correctly passed to sub functions. The > buffer size is specified as ?NI_MAXHOST + 1?, so this size should be > handed down to gethostname() and getnameinfo() calls, not just > NI_MAXHOST. I also moved the solaris #ifdefs into the else clause to > spare a few lines of code. > I think, it is intentional to handle case where return "hostname" is to large to fit in? array.? if you see the man page(http://man7.org/linux/man-pages/man2/gethostname.2.html) it says that it is unspecified whether returned buffer includes a terminating null byte. current code will put null in case of large "hostname", What do you think ? Thanks, Vyom > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202181 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202181.0/ > > > Thanks > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Apr 24 11:15:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Apr 2018 11:15:00 +0000 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: Message-ID: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> Hi Vyom, > I think, it is intentional to handle case where return "hostname" is to large to > fit in? array.? if you see the man page(http://man7.org/linux/man- > pages/man2/gethostname.2.html) it says that it is unspecified whether > returned buffer includes a terminating null byte. > > current code will put null in case of large "hostname", What do you think ? yes, I had read the man page and saw this point of the spec. But exactly for this purpose there's this code: // make sure string is null-terminated hostname[NI_MAXHOST] = '\0'; If we only hand 'NI_MAXHOST' as size value into gethostname, then the function might only write NI_MAXHOST - 1 characters of the hostname into the buffer. Best regards Christoph From vyom.tewari at oracle.com Tue Apr 24 13:23:37 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 24 Apr 2018 18:53:37 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: Hi Alan, Thanks for review comments, please find my answers inline. Vyom On Monday 23 April 2018 06:04 PM, Alan Bateman wrote: > On 23/04/2018 13:05, vyom tewari wrote: >> Hi, >> >> Please find the latest >> webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). >> I incorporated? most of the review comments. > This looks much better but I think the second paragraph of the spec of > each option needs to be inverted so that it states clearly what the > options does before it gets into the background of SO_KEEPALIVE. For > example, TCP_KEEPALIVE should say that it sets the idle period for > keep alive before it explains SO_KEEPALIVE. The currently wording also > begs questions as to whether the socket option means anything when > SO_KEEPALIVE is not enabled. Also it probably should say something > about whether it can be changed at any time or not. > > The implementation looks much better but the filtering by socket > option name is still a bit fragile. It might be better for > ExtendedSocketOptions to mainain 3 sets of options, one for > SOCK_UNSPEC, one for SOCK_STREAM, the other for SOCK_DGRAM. A map > would work too. The register method can specify socket type and it's > very obvious which sockets the option is intended to be used for. I choose to overload the "options(short type)" over maintain multiple set of options because it was straight forward and? minimal changes were required. If i split the extended options to multiple set then it will increases the complexity i have to change the register method and i have to change "ifOptionSupported" as well. i feel it is not worth because we are not going to add socket options frequently. > > All usages are now ExtendedSocketOptions.getInstance().options(...). > Have you considered a static options(...) method to reduce the typing > at each of the usage sites? no, let me check if we can consider static options(..) method. > > -Alan From ivan.gerasimov at oracle.com Tue Apr 24 16:42:35 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 24 Apr 2018 09:42:35 -0700 Subject: RFR 8202154 : Remove unused code in java.base/windows/native/libnet In-Reply-To: <25611d51-96af-a403-73fd-d82bc094dc3d@oracle.com> References: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> <0ff6798e-58e0-e26d-1972-289772dd1e9e@oracle.com> <25611d51-96af-a403-73fd-d82bc094dc3d@oracle.com> Message-ID: Hi Vyom! On 4/23/18 11:29 PM, vyom tewari wrote: > > Hi Ivan, > > code looks good to me, thanks for doing this cleanup. One minor > comment, in PortConfig.java you can make defaultUpper& defaultLower as > final. > Yes, of course, they should be final! I'll add it before pushing. > I see that Microsoft changed dynamic port range recently do we need to > put some comment in PortConfig.java ? > Can you give a link to a document about what the new range is? In msdn I could only see that the default range in Vista and later is [49152, 65535], just as it is hardcoded in JDK. With kind regards, Ivan > Thanks, Vyom > > On Tuesday 24 April 2018 09:47 AM, Ivan Gerasimov wrote: >> Hello again! >> >> A few other files contain obsolete code, so they can be combined >> together in one fix. >> >> The webrev was updated in place: >> http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ >> >> Here's the summary of additional changes: >> - sun.net.PortConfig.getLower()/getUpper() always return the same >> range, so it can be defined with constants, >> - NET_GetDefaultTOS() always returns zero, so it can be removed. >> >> Would you please help review this? >> >> With kind regards, >> Ivan >> >> On 4/23/18 2:29 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Some code in TwoStacksPlainDatagramSocketImpl.c is only relevant for >>> earlier versions of Windows, which are no longer supported as of JDK >>> 11. >>> This code can be safely removed. >>> >>> Also removing an unused argument at >>> DualStackPlainDatagramSocketImpl.socketCreate(). >>> >>> Would you please help review this cleanup? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ >>> >>> Thanks in advance! >>> >> > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Wed Apr 25 08:00:02 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Wed, 25 Apr 2018 13:30:02 +0530 Subject: RFR 8202154 : Remove unused code in java.base/windows/native/libnet In-Reply-To: References: <976ed263-2569-03d4-231f-e3400caab458@oracle.com> <0ff6798e-58e0-e26d-1972-289772dd1e9e@oracle.com> <25611d51-96af-a403-73fd-d82bc094dc3d@oracle.com> Message-ID: <9a453e0e-5db0-74d8-bc7f-1a3c10e6b56e@oracle.com> On Tuesday 24 April 2018 10:12 PM, Ivan Gerasimov wrote: > > Hi Vyom! > > > On 4/23/18 11:29 PM, vyom tewari wrote: >> >> Hi Ivan, >> >> code looks good to me, thanks for doing this cleanup. One minor >> comment, in PortConfig.java you can make defaultUpper& defaultLower >> as final. >> > Yes, of course, they should be final!? I'll add it before pushing. > >> I see that Microsoft changed dynamic port range recently do we need >> to put some comment in PortConfig.java ? >> > Can you give a link to a document about what the new range is? > In msdn I could only see that the default range in Vista and later is > [49152, 65535], just as it is hardcoded in JDK. > I think i saw the following link(https://support.microsoft.com/en-in/help/929851/the-default-dynamic-port-range-for-tcp-ip-has-changed-in-windows-vista) which tells it changed from (1025,5000) --> (49152,65535) . Do we support older windows (prior vista)?, if not then it is fine to use (49152,65535) . Thanks, Vyom > With kind regards, > Ivan > >> Thanks, Vyom >> >> On Tuesday 24 April 2018 09:47 AM, Ivan Gerasimov wrote: >>> Hello again! >>> >>> A few other files contain obsolete code, so they can be combined >>> together in one fix. >>> >>> The webrev was updated in place: >>> http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ >>> >>> Here's the summary of additional changes: >>> - sun.net.PortConfig.getLower()/getUpper() always return the same >>> range, so it can be defined with constants, >>> - NET_GetDefaultTOS() always returns zero, so it can be removed. >>> >>> Would you please help review this? >>> >>> With kind regards, >>> Ivan >>> >>> On 4/23/18 2:29 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Some code in TwoStacksPlainDatagramSocketImpl.c is only relevant >>>> for earlier versions of Windows, which are no longer supported as >>>> of JDK 11. >>>> This code can be safely removed. >>>> >>>> Also removing an unused argument at >>>> DualStackPlainDatagramSocketImpl.socketCreate(). >>>> >>>> Would you please help review this cleanup? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/ >>>> >>>> Thanks in advance! >>>> >>> >> > > -- > With kind regards, > Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Apr 26 10:18:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Apr 2018 10:18:00 +0000 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> Message-ID: <81a9aca81a5e4cf2aa13f36a71b3a40f@sap.com> Hi Vyom, what about my suggestions for renaming? src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java -> src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c -> src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c This would be more consistent as we have: src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java ... src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c src/jdk.net/solaris/classes/jdk/net/SolarisSocketOptions.java Thanks Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > vyom tewari > Sent: Montag, 23. April 2018 14:06 > To: Chris Hegarty ; OpenJDK Network Dev list > > Subject: Re: RFR:8194298 Add support for per Socket configuration of TCP > keepalive > > Hi, > > Please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.htm > l). > I incorporated? most of the review comments. > > Thanks, > > Vyom > > > On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: > > Vyom, > > > > On 13/04/18 10:50, vyom tewari wrote: > >> Hi All, > >> > >> Please review the below code. > >> > >> BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 > >> > >> webrev : > >> http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > > > > Here is some proposed wording for the JDK-specific extended socket > > options specification. > > > > 1) Uses a consistent style across all three new options, > > ?? and is in line with existing extended options. > > 2) Renamed the options slightly, to improve readability > > ?? ( they don't need to conform to the native option names ) > > 3) Reordered them so the build up is more logical > > 4) Removed inheritance from server sockets > > 5) Added standard verbiage about being "platform and > > ?? system dependent > > 6) Added typical values. I think this is useful, as it > > ?? gives an idea to the developer, but maybe it could be > > ?? misleading. Can be dropped if there are concerns. > > > > Can you please confirm that this is accurate, and also > > will leave enough "wriggle" room when additional platform > > support is added. > > > > --- > > > > ??? /** > > ???? * Keep-Alive idle time. > > ???? * > > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > > has been > > ???? * idle for some amount of time. The default value for this idle > > period is > > ???? * system dependent, but is typically 2 hours. The {@code > > TCP_KEEPIDLE} > > ???? * option can be used to affect this value for a given socket. > > ???? * > > ???? *

The value of this socket option is an {@code Integer} that > > is the > > ???? * number of seconds of idle time before keep-alive initiates a > > probe. The > > ???? * socket option is specific to stream-oriented sockets using the > > TCP/IP > > ???? * protocol. The exact semantics of this socket option are socket > > type and > > ???? * system dependent. > > ???? * > > ???? *? @since 11 > > ???? */ > > ??? public static final SocketOption TCP_KEEPIDLE > > ??????????? = new ExtSocketOption("TCP_KEEPIDLE", > > Integer.class); > > > > ??? /** > > ???? * Keep-Alive retransmission interval time. > > ???? * > > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > > has been > > ???? * idle for some amount of time. If the remote system does not > > respond to a > > ???? * keep-alive probe, TCP retransmits the probe after some amount > > of time. > > ???? * The default value for this retransmition interval is system > > dependent, > > ???? * but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} > > option can be > > ???? * used to affect this value for a given socket. > > ???? * > > ???? *

The value of this socket option is an {@code Integer} that > > is the > > ???? * number of seconds to wait before retransmitting a keep-alive > > probe. The > > ???? * socket option is specific to stream-oriented sockets using the > > TCP/IP > > ???? * protocol. The exact semantics of this socket option are socket > > type and > > ???? * system dependent. > > ???? * > > ???? * @since 11 > > ???? */ > > ??? public static final SocketOption TCP_KEEPINTERVAL > > ??????????? = new ExtSocketOption("TCP_KEEPINTERVAL", > > Integer.class); > > > > ??? /** > > ???? * Keep-Alive retransmission maximum limit. > > ???? * > > ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE > > ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > > has been > > ???? * idle for some amount of time. If the remote system does not > > respond to a > > ???? * keep-alive probe, TCP retransmits the probe a certain number of > > times > > ???? * before a connection is considered to be broken. The default > > value for > > ???? * this keep-alive probe retransmit limit is system dependent, but is > > ???? * typically 8. The {@code TCP_KEEPCOUNT} option can be used to > > affect > > ???? * this value for a given socket. > > ???? * > > ???? *

The value of this socket option is an {@code Integer} that > > is the > > ???? * maximum number of keep-alive probes to be sent. The socket > > option is > > ???? * specific to stream-oriented sockets using the TCP/IP protocol. > > The exact > > ???? * semantics of this socket option are socket type and system > > dependent. > > ???? * > > ???? * @since 11 > > ???? */ > > ??? public static final SocketOption TCP_KEEPCOUNT > > ??????????? = new ExtSocketOption("TCP_KEEPCOUNT", > > Integer.class); > > > > -Chris. From vyom.tewari at oracle.com Thu Apr 26 10:30:45 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Thu, 26 Apr 2018 16:00:45 +0530 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <81a9aca81a5e4cf2aa13f36a71b3a40f@sap.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> <81a9aca81a5e4cf2aa13f36a71b3a40f@sap.com> Message-ID: <9c523a06-438e-a343-45ad-6abfa65fb8c6@oracle.com> On Thursday 26 April 2018 03:48 PM, Langer, Christoph wrote: > Hi Vyom, > > what about my suggestions for renaming? > > src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java -> src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java > src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c -> src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c till now we don't have file name like MacOSX***** so i choose to leave as it is but if people think "MacOSXSocketOption" is more appropriate, i will change the filename name in my next webrev. Thanks, Vyom > > This would be more consistent as we have: > src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c > src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java > ... > src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c > src/jdk.net/solaris/classes/jdk/net/SolarisSocketOptions.java > > Thanks > Christoph > >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of >> vyom tewari >> Sent: Montag, 23. April 2018 14:06 >> To: Chris Hegarty ; OpenJDK Network Dev list >> >> Subject: Re: RFR:8194298 Add support for per Socket configuration of TCP >> keepalive >> >> Hi, >> >> Please find the latest >> webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.htm >> l). >> I incorporated? most of the review comments. >> >> Thanks, >> >> Vyom >> >> >> On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: >>> Vyom, >>> >>> On 13/04/18 10:50, vyom tewari wrote: >>>> Hi All, >>>> >>>> Please review the below code. >>>> >>>> BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 >>>> >>>> webrev : >>>> http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html >>> Here is some proposed wording for the JDK-specific extended socket >>> options specification. >>> >>> 1) Uses a consistent style across all three new options, >>> ?? and is in line with existing extended options. >>> 2) Renamed the options slightly, to improve readability >>> ?? ( they don't need to conform to the native option names ) >>> 3) Reordered them so the build up is more logical >>> 4) Removed inheritance from server sockets >>> 5) Added standard verbiage about being "platform and >>> ?? system dependent >>> 6) Added typical values. I think this is useful, as it >>> ?? gives an idea to the developer, but maybe it could be >>> ?? misleading. Can be dropped if there are concerns. >>> >>> Can you please confirm that this is accurate, and also >>> will leave enough "wriggle" room when additional platform >>> support is added. >>> >>> --- >>> >>> ??? /** >>> ???? * Keep-Alive idle time. >>> ???? * >>> ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE >>> ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that >>> has been >>> ???? * idle for some amount of time. The default value for this idle >>> period is >>> ???? * system dependent, but is typically 2 hours. The {@code >>> TCP_KEEPIDLE} >>> ???? * option can be used to affect this value for a given socket. >>> ???? * >>> ???? *

The value of this socket option is an {@code Integer} that >>> is the >>> ???? * number of seconds of idle time before keep-alive initiates a >>> probe. The >>> ???? * socket option is specific to stream-oriented sockets using the >>> TCP/IP >>> ???? * protocol. The exact semantics of this socket option are socket >>> type and >>> ???? * system dependent. >>> ???? * >>> ???? *? @since 11 >>> ???? */ >>> ??? public static final SocketOption TCP_KEEPIDLE >>> ??????????? = new ExtSocketOption("TCP_KEEPIDLE", >>> Integer.class); >>> >>> ??? /** >>> ???? * Keep-Alive retransmission interval time. >>> ???? * >>> ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE >>> ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that >>> has been >>> ???? * idle for some amount of time. If the remote system does not >>> respond to a >>> ???? * keep-alive probe, TCP retransmits the probe after some amount >>> of time. >>> ???? * The default value for this retransmition interval is system >>> dependent, >>> ???? * but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} >>> option can be >>> ???? * used to affect this value for a given socket. >>> ???? * >>> ???? *

The value of this socket option is an {@code Integer} that >>> is the >>> ???? * number of seconds to wait before retransmitting a keep-alive >>> probe. The >>> ???? * socket option is specific to stream-oriented sockets using the >>> TCP/IP >>> ???? * protocol. The exact semantics of this socket option are socket >>> type and >>> ???? * system dependent. >>> ???? * >>> ???? * @since 11 >>> ???? */ >>> ??? public static final SocketOption TCP_KEEPINTERVAL >>> ??????????? = new ExtSocketOption("TCP_KEEPINTERVAL", >>> Integer.class); >>> >>> ??? /** >>> ???? * Keep-Alive retransmission maximum limit. >>> ???? * >>> ???? *

When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE >>> ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that >>> has been >>> ???? * idle for some amount of time. If the remote system does not >>> respond to a >>> ???? * keep-alive probe, TCP retransmits the probe a certain number of >>> times >>> ???? * before a connection is considered to be broken. The default >>> value for >>> ???? * this keep-alive probe retransmit limit is system dependent, but is >>> ???? * typically 8. The {@code TCP_KEEPCOUNT} option can be used to >>> affect >>> ???? * this value for a given socket. >>> ???? * >>> ???? *

The value of this socket option is an {@code Integer} that >>> is the >>> ???? * maximum number of keep-alive probes to be sent. The socket >>> option is >>> ???? * specific to stream-oriented sockets using the TCP/IP protocol. >>> The exact >>> ???? * semantics of this socket option are socket type and system >>> dependent. >>> ???? * >>> ???? * @since 11 >>> ???? */ >>> ??? public static final SocketOption TCP_KEEPCOUNT >>> ??????????? = new ExtSocketOption("TCP_KEEPCOUNT", >>> Integer.class); >>> >>> -Chris. From christoph.langer at sap.com Thu Apr 26 10:33:20 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Apr 2018 10:33:20 +0000 Subject: RFR:8194298 Add support for per Socket configuration of TCP keepalive In-Reply-To: <9c523a06-438e-a343-45ad-6abfa65fb8c6@oracle.com> References: <29be358c-8762-fbc7-80dd-f09fbf47ed4a@oracle.com> <81a9aca81a5e4cf2aa13f36a71b3a40f@sap.com> <9c523a06-438e-a343-45ad-6abfa65fb8c6@oracle.com> Message-ID: <136a70124f8f4e7f98f9fc51573eaa73@sap.com> Ok, let's get some more opinions on that... ?? > -----Original Message----- > From: vyom tewari [mailto:vyom.tewari at oracle.com] > Sent: Donnerstag, 26. April 2018 12:31 > To: Langer, Christoph ; Chris Hegarty > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: Re: RFR:8194298 Add support for per Socket configuration of TCP > keepalive > > > > On Thursday 26 April 2018 03:48 PM, Langer, Christoph wrote: > > Hi Vyom, > > > > what about my suggestions for renaming? > > > > src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java -> > src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java > > src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c -> > src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c > till now we don't have file name like MacOSX***** so i choose to leave > as it is but if people think "MacOSXSocketOption" is more appropriate, i > will change the filename name in my next webrev. > > Thanks, > Vyom > > > > This would be more consistent as we have: > > src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c > > src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java > > ... > > src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c > > src/jdk.net/solaris/classes/jdk/net/SolarisSocketOptions.java > > > > Thanks > > Christoph > > > >> -----Original Message----- > >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > >> vyom tewari > >> Sent: Montag, 23. April 2018 14:06 > >> To: Chris Hegarty ; OpenJDK Network Dev list > >> > >> Subject: Re: RFR:8194298 Add support for per Socket configuration of TCP > >> keepalive > >> > >> Hi, > >> > >> Please find the latest > >> > webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.htm > >> l). > >> I incorporated? most of the review comments. > >> > >> Thanks, > >> > >> Vyom > >> > >> > >> On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: > >>> Vyom, > >>> > >>> On 13/04/18 10:50, vyom tewari wrote: > >>>> Hi All, > >>>> > >>>> Please review the below code. > >>>> > >>>> BugId??? : https://bugs.openjdk.java.net/browse/JDK-8194298 > >>>> > >>>> webrev : > >>>> http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html > >>> Here is some proposed wording for the JDK-specific extended socket > >>> options specification. > >>> > >>> 1) Uses a consistent style across all three new options, > >>> ?? and is in line with existing extended options. > >>> 2) Renamed the options slightly, to improve readability > >>> ?? ( they don't need to conform to the native option names ) > >>> 3) Reordered them so the build up is more logical > >>> 4) Removed inheritance from server sockets > >>> 5) Added standard verbiage about being "platform and > >>> ?? system dependent > >>> 6) Added typical values. I think this is useful, as it > >>> ?? gives an idea to the developer, but maybe it could be > >>> ?? misleading. Can be dropped if there are concerns. > >>> > >>> Can you please confirm that this is accurate, and also > >>> will leave enough "wriggle" room when additional platform > >>> support is added. > >>> > >>> --- > >>> > >>> ??? /** > >>> ???? * Keep-Alive idle time. > >>> ???? * > >>> ???? *

When the {@link > java.net.StandardSocketOptions#SO_KEEPALIVE > >>> ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > >>> has been > >>> ???? * idle for some amount of time. The default value for this idle > >>> period is > >>> ???? * system dependent, but is typically 2 hours. The {@code > >>> TCP_KEEPIDLE} > >>> ???? * option can be used to affect this value for a given socket. > >>> ???? * > >>> ???? *

The value of this socket option is an {@code Integer} that > >>> is the > >>> ???? * number of seconds of idle time before keep-alive initiates a > >>> probe. The > >>> ???? * socket option is specific to stream-oriented sockets using the > >>> TCP/IP > >>> ???? * protocol. The exact semantics of this socket option are socket > >>> type and > >>> ???? * system dependent. > >>> ???? * > >>> ???? *? @since 11 > >>> ???? */ > >>> ??? public static final SocketOption TCP_KEEPIDLE > >>> ??????????? = new ExtSocketOption("TCP_KEEPIDLE", > >>> Integer.class); > >>> > >>> ??? /** > >>> ???? * Keep-Alive retransmission interval time. > >>> ???? * > >>> ???? *

When the {@link > java.net.StandardSocketOptions#SO_KEEPALIVE > >>> ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > >>> has been > >>> ???? * idle for some amount of time. If the remote system does not > >>> respond to a > >>> ???? * keep-alive probe, TCP retransmits the probe after some amount > >>> of time. > >>> ???? * The default value for this retransmition interval is system > >>> dependent, > >>> ???? * but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} > >>> option can be > >>> ???? * used to affect this value for a given socket. > >>> ???? * > >>> ???? *

The value of this socket option is an {@code Integer} that > >>> is the > >>> ???? * number of seconds to wait before retransmitting a keep-alive > >>> probe. The > >>> ???? * socket option is specific to stream-oriented sockets using the > >>> TCP/IP > >>> ???? * protocol. The exact semantics of this socket option are socket > >>> type and > >>> ???? * system dependent. > >>> ???? * > >>> ???? * @since 11 > >>> ???? */ > >>> ??? public static final SocketOption TCP_KEEPINTERVAL > >>> ??????????? = new ExtSocketOption("TCP_KEEPINTERVAL", > >>> Integer.class); > >>> > >>> ??? /** > >>> ???? * Keep-Alive retransmission maximum limit. > >>> ???? * > >>> ???? *

When the {@link > java.net.StandardSocketOptions#SO_KEEPALIVE > >>> ???? * SO_KEEPALIVE} option is enabled, TCP probes a connection that > >>> has been > >>> ???? * idle for some amount of time. If the remote system does not > >>> respond to a > >>> ???? * keep-alive probe, TCP retransmits the probe a certain number of > >>> times > >>> ???? * before a connection is considered to be broken. The default > >>> value for > >>> ???? * this keep-alive probe retransmit limit is system dependent, but is > >>> ???? * typically 8. The {@code TCP_KEEPCOUNT} option can be used to > >>> affect > >>> ???? * this value for a given socket. > >>> ???? * > >>> ???? *

The value of this socket option is an {@code Integer} that > >>> is the > >>> ???? * maximum number of keep-alive probes to be sent. The socket > >>> option is > >>> ???? * specific to stream-oriented sockets using the TCP/IP protocol. > >>> The exact > >>> ???? * semantics of this socket option are socket type and system > >>> dependent. > >>> ???? * > >>> ???? * @since 11 > >>> ???? */ > >>> ??? public static final SocketOption TCP_KEEPCOUNT > >>> ??????????? = new ExtSocketOption("TCP_KEEPCOUNT", > >>> Integer.class); > >>> > >>> -Chris. From christoph.langer at sap.com Thu Apr 26 18:56:46 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Apr 2018 18:56:46 +0000 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: Message-ID: Ping, can some reviewer please have a look at this small fix? Thanks Christoph From: Langer, Christoph Sent: Dienstag, 24. April 2018 11:39 To: net-dev at openjdk.java.net Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations Hi, please help reviewing a small change that I stumbled over when looking into the getLocalHostName implementation. I found that the length of the hostname buffer is not correctly passed to sub functions. The buffer size is specified as "NI_MAXHOST + 1", so this size should be handed down to gethostname() and getnameinfo() calls, not just NI_MAXHOST. I also moved the solaris #ifdefs into the else clause to spare a few lines of code. Bug: https://bugs.openjdk.java.net/browse/JDK-8202181 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202181.0/ Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Apr 26 20:29:58 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 26 Apr 2018 13:29:58 -0700 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: Message-ID: Hi Christoph, This looks OK to me but probably a net-dev engineer should also comment. The bug needs a noreg label, e.g., noreg-cleanup. Brian On Apr 26, 2018, at 11:56 AM, Langer, Christoph wrote: > Ping, can some reviewer please have a look at this small fix? > [?] > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202181 > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8202181.0/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Fri Apr 27 03:57:33 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 27 Apr 2018 09:27:33 +0530 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> Message-ID: Hi Christoph, On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: > Hi Vyom, > >> I think, it is intentional to handle case where return "hostname" is to large to >> fit in? array.? if you see the man page(http://man7.org/linux/man- >> pages/man2/gethostname.2.html) it says that it is unspecified whether >> returned buffer includes a terminating null byte. >> >> current code will put null in case of large "hostname", What do you think ? > yes, I had read the man page and saw this point of the spec. But exactly for this purpose there's this code: > > // make sure string is null-terminated > hostname[NI_MAXHOST] = '\0'; > > If we only hand 'NI_MAXHOST' as size value into gethostname, then the function might only write NI_MAXHOST - 1 characters of the hostname into the buffer. doc says it will copy len bytes into buffer and will not copy null character into the buffer. ################################ *C library/kernel differences* The GNU C library does not employ the*gethostname*() system call; instead, it implements*gethostname*() as a library function that calls uname(2) and copies up to/len/ bytes from the returned/nodename/ field into/name/. Having performed the copy, the function then checks if the length of the/nodename/ was greater than or equal to/len/, and if it is, then the function returns -1 with/errno / set to*ENAMETOOLONG*; in this case, a terminating null byte is not included in the returned /name/. ############################################################ Just for curiosity, are we facing any issues with the current code ?. Your code change looks logical but if nothing is broken then why to change code. Thanks, Vyom > > Best regards > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Apr 27 05:02:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 07:02:57 +0200 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: Message-ID: Hi Christoph, code change makes sense. +1 on the "sizeof()" arg change. I would prefer it though if you would move the zero-termination out of the if/else altogether. Best Regards, Thomas On Tue, Apr 24, 2018 at 11:38 AM, Langer, Christoph wrote: > Hi, > > > > please help reviewing a small change that I stumbled over when looking into > the getLocalHostName implementation. I found that the length of the hostname > buffer is not correctly passed to sub functions. The buffer size is > specified as ?NI_MAXHOST + 1?, so this size should be handed down to > gethostname() and getnameinfo() calls, not just NI_MAXHOST. I also moved the > solaris #ifdefs into the else clause to spare a few lines of code. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202181 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202181.0/ > > > > Thanks > > Christoph > > From thomas.stuefe at gmail.com Fri Apr 27 05:16:49 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 07:16:49 +0200 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: Message-ID: On Fri, Apr 27, 2018 at 7:02 AM, Thomas St?fe wrote: > Hi Christoph, > > code change makes sense. +1 on the "sizeof()" arg change. > > I would prefer it though if you would move the zero-termination out of > the if/else altogether. Disregard this last comment. What I meant was I would probably unconditionally zero-terminate the result string before calling NewStringUTF() but I guess this is not needed. ..Thomas > > Best Regards, Thomas > > > > On Tue, Apr 24, 2018 at 11:38 AM, Langer, Christoph > wrote: >> Hi, >> >> >> >> please help reviewing a small change that I stumbled over when looking into >> the getLocalHostName implementation. I found that the length of the hostname >> buffer is not correctly passed to sub functions. The buffer size is >> specified as ?NI_MAXHOST + 1?, so this size should be handed down to >> gethostname() and getnameinfo() calls, not just NI_MAXHOST. I also moved the >> solaris #ifdefs into the else clause to spare a few lines of code. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202181 >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202181.0/ >> >> >> >> Thanks >> >> Christoph >> >> From thomas.stuefe at gmail.com Fri Apr 27 05:28:40 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 07:28:40 +0200 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> Message-ID: On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari wrote: > Hi Christoph, > > > On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: > > Hi Vyom, > > I think, it is intentional to handle case where return "hostname" is to > large to > fit in array. if you see the man page(http://man7.org/linux/man- > pages/man2/gethostname.2.html) it says that it is unspecified whether > returned buffer includes a terminating null byte. > > current code will put null in case of large "hostname", What do you think ? > > yes, I had read the man page and saw this point of the spec. But exactly for > this purpose there's this code: > > // make sure string is null-terminated > hostname[NI_MAXHOST] = '\0'; > > If we only hand 'NI_MAXHOST' as size value into gethostname, then the > function might only write NI_MAXHOST - 1 characters of the hostname into the > buffer. > > doc says it will copy len bytes into buffer and will not copy null character > into the buffer. > > ################################ > > C library/kernel differences > The GNU C library does not employ the gethostname() system call; > instead, it implements gethostname() as a library function that calls > uname(2) and copies up to len bytes from the returned nodename field > into name. Having performed the copy, the function then checks if > the length of the nodename was greater than or equal to len, and if > it is, then the function returns -1 with errno set to ENAMETOOLONG; > in this case, a terminating null byte is not included in the returned > name. > ############################################################ > This is shared code, so we should refer to Posix, not linux specific man pages. http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname.html DESCRIPTION The gethostname() function shall return the standard host name for the current machine. The namelen argument shall specify the size of the array pointed to by the name argument. The returned name shall be null-terminated, except that if namelen is an insufficient length to hold the host name, then the returned name shall be truncated and it is unspecified whether the returned name is null-terminated. Host names are limited to {HOST_NAME_MAX} bytes. RETURN VALUE Upon successful completion, 0 shall be returned; otherwise, -1 shall be returned. Note that there is no indication what happens if the buffer is too small. It may zero-terminate, it may not. It may return an error, it may not. Decision is left to the platform implementors. So from that, I would pass in a large-enough buffer and always zero-terminate on success. According to Posix, a large-enough buffer means HOST_NAME_MAX bytes. I do not understand why we use NI_MAXHOST instead (and we we define it to an arbitrary 1025 byte if undefined). Were there platforms where HOST_NAME_MAX was too short? If yes, one should at least check that NI_MAXHOST >= HOST_NAME_MAX. > Just for curiosity, are we facing any issues with the current code ?. Your > code change looks logical but if nothing is broken then why to change code. > If it can be proven by looking at the API description that it is broken for some corner case, why keep it broken? Thanks, Thomas > Thanks, > Vyom > > Best regards > Christoph > > From vyom.tewari at oracle.com Fri Apr 27 06:37:37 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 27 Apr 2018 12:07:37 +0530 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> Message-ID: <998070ee-1779-149f-1849-806e259d6d55@oracle.com> On Friday 27 April 2018 10:58 AM, Thomas St?fe wrote: > On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari wrote: >> Hi Christoph, >> >> >> On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: >> >> Hi Vyom, >> >> I think, it is intentional to handle case where return "hostname" is to >> large to >> fit in array. if you see the man page(http://man7.org/linux/man- >> pages/man2/gethostname.2.html) it says that it is unspecified whether >> returned buffer includes a terminating null byte. >> >> current code will put null in case of large "hostname", What do you think ? >> >> yes, I had read the man page and saw this point of the spec. But exactly for >> this purpose there's this code: >> >> // make sure string is null-terminated >> hostname[NI_MAXHOST] = '\0'; >> >> If we only hand 'NI_MAXHOST' as size value into gethostname, then the >> function might only write NI_MAXHOST - 1 characters of the hostname into the >> buffer. >> >> doc says it will copy len bytes into buffer and will not copy null character >> into the buffer. >> >> ################################ >> >> C library/kernel differences >> The GNU C library does not employ the gethostname() system call; >> instead, it implements gethostname() as a library function that calls >> uname(2) and copies up to len bytes from the returned nodename field >> into name. Having performed the copy, the function then checks if >> the length of the nodename was greater than or equal to len, and if >> it is, then the function returns -1 with errno set to ENAMETOOLONG; >> in this case, a terminating null byte is not included in the returned >> name. >> ############################################################ >> > This is shared code, so we should refer to Posix, not linux specific man pages. > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname.html > > > > DESCRIPTION > > The gethostname() function shall return the standard host name for the > current machine. The namelen argument shall specify the size of the > array pointed to by the name argument. The returned name shall be > null-terminated, except that if namelen is an insufficient length to > hold the host name, then the returned name shall be truncated and it > is unspecified whether the returned name is null-terminated. > > Host names are limited to {HOST_NAME_MAX} bytes. > > RETURN VALUE > > Upon successful completion, 0 shall be returned; otherwise, -1 shall > be returned. > > > > Note that there is no indication what happens if the buffer is too > small. It may zero-terminate, it may not. It may return an error, it > may not. Decision is left to the platform implementors. > > So from that, I would pass in a large-enough buffer and always > zero-terminate on success. According to Posix, a large-enough buffer > means HOST_NAME_MAX bytes. > > I do not understand why we use NI_MAXHOST instead (and we we define it > to an arbitrary 1025 byte if undefined). Were there platforms where > HOST_NAME_MAX was too short? If yes, one should at least check that > NI_MAXHOST >= HOST_NAME_MAX. Even i noticed this, why we use our own NI_MAXHOST instead HOST_NAME_MAX ? >> Just for curiosity, are we facing any issues with the current code ?. Your >> code change looks logical but if nothing is broken then why to change code. >> > If it can be proven by looking at the API description that it is > broken for some corner case, why keep it broken? ?:) Agreed, as i said Christoph change is logically correct? but i don't know the history behind current code, so just wanted to be sure that? we are not missing any corner case. Thanks, Vyom > > Thanks, Thomas > >> Thanks, >> Vyom >> >> Best regards >> Christoph >> >> From christoph.langer at sap.com Fri Apr 27 07:35:04 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 Apr 2018 07:35:04 +0000 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: <998070ee-1779-149f-1849-806e259d6d55@oracle.com> References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> Message-ID: <7509fa931062468688224a321c7e1308@sap.com> Hi all, thanks for looking into this. Here are a few comments First of all, there are no real life issues I have seen with this. It is just something that occurred to me when working with the code. But, why not fix it, even it is a corner case that might never happen. @Thomas: As for the zero termination of the hostname result after the call to gethostname: Yes, we should unconditionally terminate the result, which we do. Unfortunately this part of code cannot be moved outside the solaris #ifdef because the part in the #ifdef contains variable declarations. And you know - the C compatibility issue... I looked again into the macro definitions for for HOST_NAME_MAX and NI_MAXHOST. HOST_NAME_MAX is mentioned in the gethostname docs ([1] and [2]). Glibc docs indicate it is 64 Byte or 255 Byte. So it looks like it is a quite small buffer, compared to NI_MAXHOST from netdb.h, which is the value that getnameinfo likes to work with, as per [3]. Posix genameinfo doc ([4]) does not mention NI_MAXHOST but Linux doc says it is 1025 which is what we'd define if it is not set. Taking this input I have updated my webrev to round things up a little bit: http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ I moved the definition of NI_MAXHOST into net_util_md.h and updated the comment a little bit to make clearer why it is there. In Inet4AddressImpl.c and Inet6AddressImpl.c I also fixed the other places where getnameinfo is called to use sizeof(buffer) instead of NI_MAXHOST. Best regards Christoph [1] http://man7.org/linux/man-pages/man2/gethostname.2.html [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html [3] http://man7.org/linux/man-pages/man3/getnameinfo.3.html [4] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo.html > -----Original Message----- > From: vyom tewari [mailto:vyom.tewari at oracle.com] > Sent: Freitag, 27. April 2018 08:38 > To: Thomas St?fe > Cc: Langer, Christoph ; net- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in > Unix Inet*AddressImpl_getLocalHostName implementations > > > > On Friday 27 April 2018 10:58 AM, Thomas St?fe wrote: > > On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari > wrote: > >> Hi Christoph, > >> > >> > >> On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: > >> > >> Hi Vyom, > >> > >> I think, it is intentional to handle case where return "hostname" is to > >> large to > >> fit in array. if you see the man page(http://man7.org/linux/man- > >> pages/man2/gethostname.2.html) it says that it is unspecified whether > >> returned buffer includes a terminating null byte. > >> > >> current code will put null in case of large "hostname", What do you think ? > >> > >> yes, I had read the man page and saw this point of the spec. But exactly > for > >> this purpose there's this code: > >> > >> // make sure string is null-terminated > >> hostname[NI_MAXHOST] = '\0'; > >> > >> If we only hand 'NI_MAXHOST' as size value into gethostname, then the > >> function might only write NI_MAXHOST - 1 characters of the hostname > into the > >> buffer. > >> > >> doc says it will copy len bytes into buffer and will not copy null character > >> into the buffer. > >> > >> ################################ > >> > >> C library/kernel differences > >> The GNU C library does not employ the gethostname() system call; > >> instead, it implements gethostname() as a library function that calls > >> uname(2) and copies up to len bytes from the returned nodename > field > >> into name. Having performed the copy, the function then checks if > >> the length of the nodename was greater than or equal to len, and if > >> it is, then the function returns -1 with errno set to ENAMETOOLONG; > >> in this case, a terminating null byte is not included in the returned > >> name. > >> > ########################################################## > ## > >> > > This is shared code, so we should refer to Posix, not linux specific man > pages. > > > > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname > .html > > > > > > > > DESCRIPTION > > > > The gethostname() function shall return the standard host name for the > > current machine. The namelen argument shall specify the size of the > > array pointed to by the name argument. The returned name shall be > > null-terminated, except that if namelen is an insufficient length to > > hold the host name, then the returned name shall be truncated and it > > is unspecified whether the returned name is null-terminated. > > > > Host names are limited to {HOST_NAME_MAX} bytes. > > > > RETURN VALUE > > > > Upon successful completion, 0 shall be returned; otherwise, -1 shall > > be returned. > > > > > > > > Note that there is no indication what happens if the buffer is too > > small. It may zero-terminate, it may not. It may return an error, it > > may not. Decision is left to the platform implementors. > > > > So from that, I would pass in a large-enough buffer and always > > zero-terminate on success. According to Posix, a large-enough buffer > > means HOST_NAME_MAX bytes. > > > > I do not understand why we use NI_MAXHOST instead (and we we define > it > > to an arbitrary 1025 byte if undefined). Were there platforms where > > HOST_NAME_MAX was too short? If yes, one should at least check that > > NI_MAXHOST >= HOST_NAME_MAX. > Even i noticed this, why we use our own NI_MAXHOST instead > HOST_NAME_MAX ? > >> Just for curiosity, are we facing any issues with the current code ?. Your > >> code change looks logical but if nothing is broken then why to change > code. > >> > > If it can be proven by looking at the API description that it is > > broken for some corner case, why keep it broken? > ?:) Agreed, as i said Christoph change is logically correct? but i > don't know the history behind current code, so just wanted to be sure > that? we are not missing any corner case. > > Thanks, > Vyom > > > > > Thanks, Thomas > > > >> Thanks, > >> Vyom > >> > >> Best regards > >> Christoph > >> > >> From vyom.tewari at oracle.com Fri Apr 27 08:40:33 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 27 Apr 2018 14:10:33 +0530 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: <7509fa931062468688224a321c7e1308@sap.com> References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> Message-ID: <950504d8-bb57-c58c-aee6-872d96ffb881@oracle.com> On Friday 27 April 2018 01:05 PM, Langer, Christoph wrote: > Hi all, > > thanks for looking into this. Here are a few comments > > First of all, there are no real life issues I have seen with this. It is just something that occurred to me when working with the code. But, why not fix it, even it is a corner case that might never happen. > > @Thomas: As for the zero termination of the hostname result after the call to gethostname: Yes, we should unconditionally terminate the result, which we do. Unfortunately this part of code cannot be moved outside the solaris #ifdef because the part in the #ifdef contains variable declarations. And you know - the C compatibility issue... > > I looked again into the macro definitions for for HOST_NAME_MAX and NI_MAXHOST. HOST_NAME_MAX is mentioned in the gethostname docs ([1] and [2]). Glibc docs indicate it is 64 Byte or 255 Byte. So it looks like it is a quite small buffer, compared to NI_MAXHOST from netdb.h, which is the value that getnameinfo likes to work with, as per [3]. Posix genameinfo doc ([4]) does not mention NI_MAXHOST but Linux doc says it is 1025 which is what we'd define if it is not set. > > Taking this input I have updated my webrev to round things up a little bit: http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ it looks good to me, although i am not official reviewer. > I moved the definition of NI_MAXHOST into net_util_md.h and updated the comment a little bit to make clearer why it is there. In Inet4AddressImpl.c and Inet6AddressImpl.c I also fixed the other places where getnameinfo is called to use sizeof(buffer) instead of NI_MAXHOST. good cleanup, comment will definitely help. Thanks, Vyom > > Best regards > Christoph > > [1] http://man7.org/linux/man-pages/man2/gethostname.2.html > [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html > [3] http://man7.org/linux/man-pages/man3/getnameinfo.3.html > [4] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo.html > > >> -----Original Message----- >> From: vyom tewari [mailto:vyom.tewari at oracle.com] >> Sent: Freitag, 27. April 2018 08:38 >> To: Thomas St?fe >> Cc: Langer, Christoph ; net- >> dev at openjdk.java.net >> Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in >> Unix Inet*AddressImpl_getLocalHostName implementations >> >> >> >> On Friday 27 April 2018 10:58 AM, Thomas St?fe wrote: >>> On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari >> wrote: >>>> Hi Christoph, >>>> >>>> >>>> On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: >>>> >>>> Hi Vyom, >>>> >>>> I think, it is intentional to handle case where return "hostname" is to >>>> large to >>>> fit in array. if you see the man page(http://man7.org/linux/man- >>>> pages/man2/gethostname.2.html) it says that it is unspecified whether >>>> returned buffer includes a terminating null byte. >>>> >>>> current code will put null in case of large "hostname", What do you think ? >>>> >>>> yes, I had read the man page and saw this point of the spec. But exactly >> for >>>> this purpose there's this code: >>>> >>>> // make sure string is null-terminated >>>> hostname[NI_MAXHOST] = '\0'; >>>> >>>> If we only hand 'NI_MAXHOST' as size value into gethostname, then the >>>> function might only write NI_MAXHOST - 1 characters of the hostname >> into the >>>> buffer. >>>> >>>> doc says it will copy len bytes into buffer and will not copy null character >>>> into the buffer. >>>> >>>> ################################ >>>> >>>> C library/kernel differences >>>> The GNU C library does not employ the gethostname() system call; >>>> instead, it implements gethostname() as a library function that calls >>>> uname(2) and copies up to len bytes from the returned nodename >> field >>>> into name. Having performed the copy, the function then checks if >>>> the length of the nodename was greater than or equal to len, and if >>>> it is, then the function returns -1 with errno set to ENAMETOOLONG; >>>> in this case, a terminating null byte is not included in the returned >>>> name. >>>> >> ########################################################## >> ## >>> This is shared code, so we should refer to Posix, not linux specific man >> pages. >>> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname >> .html >>> >>> >>> DESCRIPTION >>> >>> The gethostname() function shall return the standard host name for the >>> current machine. The namelen argument shall specify the size of the >>> array pointed to by the name argument. The returned name shall be >>> null-terminated, except that if namelen is an insufficient length to >>> hold the host name, then the returned name shall be truncated and it >>> is unspecified whether the returned name is null-terminated. >>> >>> Host names are limited to {HOST_NAME_MAX} bytes. >>> >>> RETURN VALUE >>> >>> Upon successful completion, 0 shall be returned; otherwise, -1 shall >>> be returned. >>> >>> >>> >>> Note that there is no indication what happens if the buffer is too >>> small. It may zero-terminate, it may not. It may return an error, it >>> may not. Decision is left to the platform implementors. >>> >>> So from that, I would pass in a large-enough buffer and always >>> zero-terminate on success. According to Posix, a large-enough buffer >>> means HOST_NAME_MAX bytes. >>> >>> I do not understand why we use NI_MAXHOST instead (and we we define >> it >>> to an arbitrary 1025 byte if undefined). Were there platforms where >>> HOST_NAME_MAX was too short? If yes, one should at least check that >>> NI_MAXHOST >= HOST_NAME_MAX. >> Even i noticed this, why we use our own NI_MAXHOST instead >> HOST_NAME_MAX ? >>>> Just for curiosity, are we facing any issues with the current code ?. Your >>>> code change looks logical but if nothing is broken then why to change >> code. >>> If it can be proven by looking at the API description that it is >>> broken for some corner case, why keep it broken? >> ?:) Agreed, as i said Christoph change is logically correct? but i >> don't know the history behind current code, so just wanted to be sure >> that? we are not missing any corner case. >> >> Thanks, >> Vyom >> >>> Thanks, Thomas >>> >>>> Thanks, >>>> Vyom >>>> >>>> Best regards >>>> Christoph >>>> >>>> From thomas.stuefe at gmail.com Fri Apr 27 16:14:41 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 18:14:41 +0200 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: <7509fa931062468688224a321c7e1308@sap.com> References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> Message-ID: Hi Christoph, On Fri, Apr 27, 2018 at 9:35 AM, Langer, Christoph wrote: > Hi all, > > thanks for looking into this. Here are a few comments > > First of all, there are no real life issues I have seen with this. It is just something that occurred to me when working with the code. But, why not fix it, even it is a corner case that might never happen. > > @Thomas: As for the zero termination of the hostname result after the call to gethostname: Yes, we should unconditionally terminate the result, which we do. Unfortunately this part of code cannot be moved outside the solaris #ifdef because the part in the #ifdef contains variable declarations. And you know - the C compatibility issue... > Ok. > I looked again into the macro definitions for for HOST_NAME_MAX and NI_MAXHOST. HOST_NAME_MAX is mentioned in the gethostname docs ([1] and [2]). Glibc docs indicate it is 64 Byte or 255 Byte. So it looks like it is a quite small buffer, compared to NI_MAXHOST from netdb.h, which is the value that getnameinfo likes to work with, as per [3]. Posix genameinfo doc ([4]) does not mention NI_MAXHOST but Linux doc says it is 1025 which is what we'd define if it is not set. > Okay, thanks for the research! This is weird, why two different defines for the same thing. The only (probably highly theoretical) problem I see is that there may be platforms which do not define NI_MAXHOST but where HOST_MAX_NAME is defined and larger than 1025 char sized output buffers. Then, we would artificially limit ourselves to 1025 characters. (Was Matthias not working on a problem with truncated host names in our hpux port?). One could in theory solve this by falling back to HOST_MAX_NAME if NI_MAXHOST is undefined: #ifdnef NI_MAXHOST #ifdef HOST_MAX_NAME #define NI_MAXHOST HOST_MAX_NAME #else #define NI_MAXHOST 1025 #endif #endif However, I am fine with your current patch. I think redefinition of NI_MAXHOST - if even necessary - should be done in a follow up issue. > Taking this input I have updated my webrev to round things up a little bit: http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ > > I moved the definition of NI_MAXHOST into net_util_md.h and updated the comment a little bit to make clearer why it is there. In Inet4AddressImpl.c and Inet6AddressImpl.c I also fixed the other places where getnameinfo is called to use sizeof(buffer) instead of NI_MAXHOST. > All looks well. Again, thanks for the research. ... Thomas > Best regards > Christoph > > [1] http://man7.org/linux/man-pages/man2/gethostname.2.html > [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html > [3] http://man7.org/linux/man-pages/man3/getnameinfo.3.html > [4] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo.html > > >> -----Original Message----- >> From: vyom tewari [mailto:vyom.tewari at oracle.com] >> Sent: Freitag, 27. April 2018 08:38 >> To: Thomas St?fe >> Cc: Langer, Christoph ; net- >> dev at openjdk.java.net >> Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in >> Unix Inet*AddressImpl_getLocalHostName implementations >> >> >> >> On Friday 27 April 2018 10:58 AM, Thomas St?fe wrote: >> > On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari >> wrote: >> >> Hi Christoph, >> >> >> >> >> >> On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: >> >> >> >> Hi Vyom, >> >> >> >> I think, it is intentional to handle case where return "hostname" is to >> >> large to >> >> fit in array. if you see the man page(http://man7.org/linux/man- >> >> pages/man2/gethostname.2.html) it says that it is unspecified whether >> >> returned buffer includes a terminating null byte. >> >> >> >> current code will put null in case of large "hostname", What do you think ? >> >> >> >> yes, I had read the man page and saw this point of the spec. But exactly >> for >> >> this purpose there's this code: >> >> >> >> // make sure string is null-terminated >> >> hostname[NI_MAXHOST] = '\0'; >> >> >> >> If we only hand 'NI_MAXHOST' as size value into gethostname, then the >> >> function might only write NI_MAXHOST - 1 characters of the hostname >> into the >> >> buffer. >> >> >> >> doc says it will copy len bytes into buffer and will not copy null character >> >> into the buffer. >> >> >> >> ################################ >> >> >> >> C library/kernel differences >> >> The GNU C library does not employ the gethostname() system call; >> >> instead, it implements gethostname() as a library function that calls >> >> uname(2) and copies up to len bytes from the returned nodename >> field >> >> into name. Having performed the copy, the function then checks if >> >> the length of the nodename was greater than or equal to len, and if >> >> it is, then the function returns -1 with errno set to ENAMETOOLONG; >> >> in this case, a terminating null byte is not included in the returned >> >> name. >> >> >> ########################################################## >> ## >> >> >> > This is shared code, so we should refer to Posix, not linux specific man >> pages. >> > >> > >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname >> .html >> > >> > >> > >> > DESCRIPTION >> > >> > The gethostname() function shall return the standard host name for the >> > current machine. The namelen argument shall specify the size of the >> > array pointed to by the name argument. The returned name shall be >> > null-terminated, except that if namelen is an insufficient length to >> > hold the host name, then the returned name shall be truncated and it >> > is unspecified whether the returned name is null-terminated. >> > >> > Host names are limited to {HOST_NAME_MAX} bytes. >> > >> > RETURN VALUE >> > >> > Upon successful completion, 0 shall be returned; otherwise, -1 shall >> > be returned. >> > >> > >> > >> > Note that there is no indication what happens if the buffer is too >> > small. It may zero-terminate, it may not. It may return an error, it >> > may not. Decision is left to the platform implementors. >> > >> > So from that, I would pass in a large-enough buffer and always >> > zero-terminate on success. According to Posix, a large-enough buffer >> > means HOST_NAME_MAX bytes. >> > >> > I do not understand why we use NI_MAXHOST instead (and we we define >> it >> > to an arbitrary 1025 byte if undefined). Were there platforms where >> > HOST_NAME_MAX was too short? If yes, one should at least check that >> > NI_MAXHOST >= HOST_NAME_MAX. >> Even i noticed this, why we use our own NI_MAXHOST instead >> HOST_NAME_MAX ? >> >> Just for curiosity, are we facing any issues with the current code ?. Your >> >> code change looks logical but if nothing is broken then why to change >> code. >> >> >> > If it can be proven by looking at the API description that it is >> > broken for some corner case, why keep it broken? >> :) Agreed, as i said Christoph change is logically correct but i >> don't know the history behind current code, so just wanted to be sure >> that we are not missing any corner case. >> >> Thanks, >> Vyom >> >> > >> > Thanks, Thomas >> > >> >> Thanks, >> >> Vyom >> >> >> >> Best regards >> >> Christoph >> >> >> >> > From christoph.langer at sap.com Mon Apr 30 08:00:55 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Apr 2018 08:00:55 +0000 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> Message-ID: Hi Thomas, thanks for reviewing. The test has also passed our internal testing. I'll run it through jdk-submit and then push it in the course of the day. Best regards Christoph > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Freitag, 27. April 2018 18:15 > To: Langer, Christoph > Cc: vyom tewari ; net-dev at openjdk.java.net; > Brian Burkhalter > Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in > Unix Inet*AddressImpl_getLocalHostName implementations > > Hi Christoph, > > On Fri, Apr 27, 2018 at 9:35 AM, Langer, Christoph > wrote: > > Hi all, > > > > thanks for looking into this. Here are a few comments > > > > First of all, there are no real life issues I have seen with this. It is just > something that occurred to me when working with the code. But, why not fix > it, even it is a corner case that might never happen. > > > > @Thomas: As for the zero termination of the hostname result after the call > to gethostname: Yes, we should unconditionally terminate the result, which > we do. Unfortunately this part of code cannot be moved outside the solaris > #ifdef because the part in the #ifdef contains variable declarations. And you > know - the C compatibility issue... > > > > Ok. > > > I looked again into the macro definitions for for HOST_NAME_MAX and > NI_MAXHOST. HOST_NAME_MAX is mentioned in the gethostname docs > ([1] and [2]). Glibc docs indicate it is 64 Byte or 255 Byte. So it looks like it is a > quite small buffer, compared to NI_MAXHOST from netdb.h, which is the > value that getnameinfo likes to work with, as per [3]. Posix genameinfo doc > ([4]) does not mention NI_MAXHOST but Linux doc says it is 1025 which is > what we'd define if it is not set. > > > > Okay, thanks for the research! This is weird, why two different > defines for the same thing. > > The only (probably highly theoretical) problem I see is that there may > be platforms which do not define NI_MAXHOST but where > HOST_MAX_NAME is > defined and larger than 1025 char sized output buffers. Then, we would > artificially limit ourselves to 1025 characters. (Was Matthias not > working on a problem with truncated host names in our hpux port?). > > One could in theory solve this by falling back to HOST_MAX_NAME if > NI_MAXHOST is undefined: > > #ifdnef NI_MAXHOST > #ifdef HOST_MAX_NAME > #define NI_MAXHOST HOST_MAX_NAME > #else > #define NI_MAXHOST 1025 > #endif > #endif > > However, I am fine with your current patch. I think redefinition of > NI_MAXHOST - if even necessary - should be done in a follow up issue. > > > Taking this input I have updated my webrev to round things up a little bit: > http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ > > > > I moved the definition of NI_MAXHOST into net_util_md.h and updated > the comment a little bit to make clearer why it is there. In Inet4AddressImpl.c > and Inet6AddressImpl.c I also fixed the other places where getnameinfo is > called to use sizeof(buffer) instead of NI_MAXHOST. > > > > All looks well. Again, thanks for the research. > > ... Thomas > > > Best regards > > Christoph > > > > [1] http://man7.org/linux/man-pages/man2/gethostname.2.html > > [2] > http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname. > html > > [3] http://man7.org/linux/man-pages/man3/getnameinfo.3.html > > [4] > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo. > html > > > > > >> -----Original Message----- > >> From: vyom tewari [mailto:vyom.tewari at oracle.com] > >> Sent: Freitag, 27. April 2018 08:38 > >> To: Thomas St?fe > >> Cc: Langer, Christoph ; net- > >> dev at openjdk.java.net > >> Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in > >> Unix Inet*AddressImpl_getLocalHostName implementations > >> > >> > >> > >> On Friday 27 April 2018 10:58 AM, Thomas St?fe wrote: > >> > On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari > > >> wrote: > >> >> Hi Christoph, > >> >> > >> >> > >> >> On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: > >> >> > >> >> Hi Vyom, > >> >> > >> >> I think, it is intentional to handle case where return "hostname" is to > >> >> large to > >> >> fit in array. if you see the man page(http://man7.org/linux/man- > >> >> pages/man2/gethostname.2.html) it says that it is unspecified > whether > >> >> returned buffer includes a terminating null byte. > >> >> > >> >> current code will put null in case of large "hostname", What do you > think ? > >> >> > >> >> yes, I had read the man page and saw this point of the spec. But > exactly > >> for > >> >> this purpose there's this code: > >> >> > >> >> // make sure string is null-terminated > >> >> hostname[NI_MAXHOST] = '\0'; > >> >> > >> >> If we only hand 'NI_MAXHOST' as size value into gethostname, then > the > >> >> function might only write NI_MAXHOST - 1 characters of the hostname > >> into the > >> >> buffer. > >> >> > >> >> doc says it will copy len bytes into buffer and will not copy null > character > >> >> into the buffer. > >> >> > >> >> ################################ > >> >> > >> >> C library/kernel differences > >> >> The GNU C library does not employ the gethostname() system call; > >> >> instead, it implements gethostname() as a library function that calls > >> >> uname(2) and copies up to len bytes from the returned nodename > >> field > >> >> into name. Having performed the copy, the function then checks if > >> >> the length of the nodename was greater than or equal to len, and > if > >> >> it is, then the function returns -1 with errno set to > ENAMETOOLONG; > >> >> in this case, a terminating null byte is not included in the returned > >> >> name. > >> >> > >> > ########################################################## > >> ## > >> >> > >> > This is shared code, so we should refer to Posix, not linux specific man > >> pages. > >> > > >> > > >> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname > >> .html > >> > > >> > > >> > > >> > DESCRIPTION > >> > > >> > The gethostname() function shall return the standard host name for the > >> > current machine. The namelen argument shall specify the size of the > >> > array pointed to by the name argument. The returned name shall be > >> > null-terminated, except that if namelen is an insufficient length to > >> > hold the host name, then the returned name shall be truncated and it > >> > is unspecified whether the returned name is null-terminated. > >> > > >> > Host names are limited to {HOST_NAME_MAX} bytes. > >> > > >> > RETURN VALUE > >> > > >> > Upon successful completion, 0 shall be returned; otherwise, -1 shall > >> > be returned. > >> > > >> > > >> > > >> > Note that there is no indication what happens if the buffer is too > >> > small. It may zero-terminate, it may not. It may return an error, it > >> > may not. Decision is left to the platform implementors. > >> > > >> > So from that, I would pass in a large-enough buffer and always > >> > zero-terminate on success. According to Posix, a large-enough buffer > >> > means HOST_NAME_MAX bytes. > >> > > >> > I do not understand why we use NI_MAXHOST instead (and we we > define > >> it > >> > to an arbitrary 1025 byte if undefined). Were there platforms where > >> > HOST_NAME_MAX was too short? If yes, one should at least check that > >> > NI_MAXHOST >= HOST_NAME_MAX. > >> Even i noticed this, why we use our own NI_MAXHOST instead > >> HOST_NAME_MAX ? > >> >> Just for curiosity, are we facing any issues with the current code ?. Your > >> >> code change looks logical but if nothing is broken then why to change > >> code. > >> >> > >> > If it can be proven by looking at the API description that it is > >> > broken for some corner case, why keep it broken? > >> :) Agreed, as i said Christoph change is logically correct but i > >> don't know the history behind current code, so just wanted to be sure > >> that we are not missing any corner case. > >> > >> Thanks, > >> Vyom > >> > >> > > >> > Thanks, Thomas > >> > > >> >> Thanks, > >> >> Vyom > >> >> > >> >> Best regards > >> >> Christoph > >> >> > >> >> > > From chris.hegarty at oracle.com Mon Apr 30 09:44:34 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Apr 2018 10:44:34 +0100 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> Message-ID: On 30/04/18 09:00, Langer, Christoph wrote: > ... >>> Taking this input I have updated my webrev to round things up a little bit: >> http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ Thank you Christophe, this latest version looks good. I'll run some tests on it and report the results by tomorrow. -Chris. P.S. I do remember adding the unconditional null termination to this code years ago, but I suspect that it's been touched a few times since. From christoph.langer at sap.com Mon Apr 30 10:07:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Apr 2018 10:07:00 +0000 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> Message-ID: <2b3c1ac625824087a1fbe8ba17036e30@sap.com> Hi Chris, thanks for looking at this. I just received positive confirmation from jdk-submit. Our internal tests did not show regressions as well. So I'll wait for word on your tests before submitting. Thanks Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Montag, 30. April 2018 11:45 > To: Langer, Christoph ; Thomas St?fe > > Cc: net-dev at openjdk.java.net > Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in > Unix Inet*AddressImpl_getLocalHostName implementations > > > On 30/04/18 09:00, Langer, Christoph wrote: > > ... > >>> Taking this input I have updated my webrev to round things up a little > bit: > >> http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ > Thank you Christophe, this latest version looks good. > I'll run some tests on it and report the results by tomorrow. > > -Chris. > > P.S. I do remember adding the unconditional null termination > to this code years ago, but I suspect that it's been touched > a few times since. From chris.hegarty at oracle.com Mon Apr 30 10:09:30 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Apr 2018 11:09:30 +0100 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: <2b3c1ac625824087a1fbe8ba17036e30@sap.com> References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> <2b3c1ac625824087a1fbe8ba17036e30@sap.com> Message-ID: On 30/04/18 11:07, Langer, Christoph wrote: > Hi Chris, > > thanks for looking at this. I just received positive confirmation from jdk-submit. Our internal tests did not show regressions as well. So I'll wait for word on your tests before submitting. Do you have a link to the jdk-submit job, or anything suitable for forwarding? I'm curious what test sets it ran. -Chris. > > Thanks > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Montag, 30. April 2018 11:45 >> To: Langer, Christoph ; Thomas St?fe >> >> Cc: net-dev at openjdk.java.net >> Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in >> Unix Inet*AddressImpl_getLocalHostName implementations >> >> >> On 30/04/18 09:00, Langer, Christoph wrote: >>> ... >>>>> Taking this input I have updated my webrev to round things up a little >> bit: >>>> http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ >> Thank you Christophe, this latest version looks good. >> I'll run some tests on it and report the results by tomorrow. >> >> -Chris. >> >> P.S. I do remember adding the unconditional null termination >> to this code years ago, but I suspect that it's been touched >> a few times since. From chris.hegarty at oracle.com Mon Apr 30 13:31:28 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Apr 2018 14:31:28 +0100 Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations In-Reply-To: References: <0e3046ea62c44836b03c3566aec5fe3e@sap.com> <998070ee-1779-149f-1849-806e259d6d55@oracle.com> <7509fa931062468688224a321c7e1308@sap.com> Message-ID: <5b781c65-7814-ca78-2fd2-7ca0c7c29041@oracle.com> On 30/04/18 10:44, Chris Hegarty wrote: > > On 30/04/18 09:00, Langer, Christoph wrote: >> ... >>>> Taking this input I have updated my webrev to round things up a >>>> little bit: >>> http://cr.openjdk.java.net/~clanger/webrevs/8202181.1/ > Thank you Christophe, this latest version looks good. > I'll run some tests on it and report the results by tomorrow. Results of my testing are positive. Reviewed. -Chris. From chris.hegarty at oracle.com Mon Apr 30 14:02:38 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Apr 2018 15:02:38 +0100 Subject: RFR [11] 8202423: Small HTTP Client refresh Message-ID: <2e8f3323-1b1f-d395-e01b-2497da80570a@oracle.com> A number of implementation changes have accumulated in the sandbox since the initial integration of the HTTP Client. The changes mainly consist of: - Test stabilization fixes. - Clean up of code left over from early prototyping. - Some small performance improvements. - General bug fixing. https://bugs.openjdk.java.net/browse/JDK-8202423 http://cr.openjdk.java.net/~chegar/8202423/00/webrev/ I author only a small portion of these changes, and have started, and will continue, to review the rest. -Chris. From chris.hegarty at oracle.com Mon Apr 30 15:14:59 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Apr 2018 16:14:59 +0100 Subject: [PATCH] JDK-8201545 Clarify the return value of InetAddress.getByName/getAllName for empty host value In-Reply-To: <98776495-d3c1-c7c1-fc92-e47785ce86d2@oracle.com> References: <62425ab1-4ca4-fad0-5478-c3174bc8fc82@gmail.com> <98776495-d3c1-c7c1-fc92-e47785ce86d2@oracle.com> Message-ID: On 23/04/18 12:33, Chris Hegarty wrote: > Thanks Jaikiran, > > I think your patch looks good. I filed the following CSR to track > the Java SE API ( javadoc ) change. > > https://bugs.openjdk.java.net/browse/JDK-8202139 > > Once approved, I can sponsor this for you. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/b7c2996d690b -Chris. From ylemoigne at javatic.fr Sun Apr 15 21:02:02 2018 From: ylemoigne at javatic.fr (Yann Le Moigne) Date: Sun, 15 Apr 2018 21:02:02 -0000 Subject: Unable to use custom authentication (because of Invalid auth header in AuthenticationFilter) Message-ID: <10E291EE-9C99-4AE3-92E9-15F020D5CF4F@javatic.fr> Hello, I tried to use the incubator/httpclient to use a rest API. This API use non standard header and a json web token for authentication. This API return 401 status when the token is missing. Currently ( java version "10" 2018-03-20 ) the response processing end with : ``` java.io.IOException: Invalid auth header at jdk.incubator.httpclient/jdk.incubator.http.AuthenticationFilter.lambda$response$1(AuthenticationFilter.java:211) ``` I did not find a way to disable this filter or workaround the issue, and the current code block my use case. Is it intended ? (I believe that 401 is agnostic about the way the auth must be performed, but I?m not sure) Any workaround to suggest ? Regards, Yann.