Introduce IOException subclass for ECONNRESET
Hi all,
I first asked this on nio-dev[0] but was asked to move this over to here:
I wonder if it would be possible to add a new IOException sub-class for
ECONNRESET. Often you receive these errors if a remote peer closed the
connection and you try to read from it while using NIO. This is very often not
really something that concerns people and can just be handled the same as a
“normal close”. At the moment the only way to detect this is to inspect the
IOException message which is really hacky. I wonder if we could not add a
special IOException sub-class for this. Something like:
ConnectionResetException extends IOException {
}
In this case it would a lot easier to handle these cases without parsing the
message and depend on some “implementation detail”. Does this sound like a good
idea ? If so I would be happy to come up with a patch against openjdk.
Thanks!
Norman
[0] http://mail.openjdk.java.net/pipermail/nio-discuss/2016-August/000732.html
Re: Introduce IOException subclass for ECONNRESET
Hi,
On Tue, Aug 23, 2016 at 9:40 AM, Norman Maurer
wrote:
> Hi all,
>
> I first asked this on nio-dev[0] but was asked to move this over to here:
>
> I wonder if it would be possible to add a new IOException sub-class for
> ECONNRESET. Often you receive these errors if a remote peer closed the
> connection and you try to read from it while using NIO. This is very often
> not really something that concerns people and can just be handled the same as
> a “normal close”. At the moment the only way to detect this is to inspect the
> IOException message which is really hacky. I wonder if we could not add a
> special IOException sub-class for this. Something like:
>
> ConnectionResetException extends IOException {
> }
>
> In this case it would a lot easier to handle these cases without parsing the
> message and depend on some “implementation detail”. Does this sound like a
> good idea ? If so I would be happy to come up with a patch against openjdk.
>
I wholeheartedly support this.
--
Simone Bordet
http://bordet.blogspot.com
---
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
Re: [9] RFR: 8164592: java/net/MulticastSocket/NoLoopbackPackets.java tests may leave a daemon thread
On 23 Aug 2016, at 03:03, Artem Smotrakov wrote: > > Hello, > > Please review the following patch for NoLoopbackPackets.java test. > > The test starts a daemon thread which has an infinite loop. If jtreg uses the > same JVM to run multiple tests (agent VM), then this thread will be keep > running until the agent VM stops. This is not good, it would be better to > stop the thread when the test is done. > > Webrev: http://cr.openjdk.java.net/~asmotrak/8164592/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8164592 This looks good. -Chris.
Re: HTTP client API
On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > There is an updated version of the HTTP client API doc [1] and a specdiff > [2] showing the changes > proposed from the current version in JDK9 dev. > > The main changes are: > > 1) The request and response processors are now based on Flow.Publisher and > Flow.Subscriber > > 2) Response bodies are retrieved synchronously with the response headers > as part of the > HttpRequest.response() and responseAsync() methods > > 3) Because of the change above, to allow code to examine the headers and > decide what to do > with the body before retrieving it, there is a new entity called a > HttpResponse.BodyHandler > which is given the status code and headers, and which returns a > HttpResponse.BodyProcessor. > Static implementations of both body handlers and body processors are > provided, to make the > simple cases easy to code. > > We are currently working in the sandbox repository again and will have > these changes > in the main JDK9 dev forest soon. > Is it possible to access the API code somewhere before then, mainly as a convenience for reviewing the APIs? > > Thanks, > > Michael > > [1] http://cr.openjdk.java.net/~michaelm/httpclient/api/ > > [2] http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout/ > package-summary.html > >
Re: HTTP client API
On Tue, Aug 23, 2016 at 12:57 PM, Wenbo Zhu wrote: > >> We are currently working in the sandbox repository again and will have >> these changes >> in the main JDK9 dev forest soon. >> > Is it possible to access the API code somewhere before then, mainly as a > convenience for reviewing the APIs? > I tried this: (Install mercurial trees extension.) hg tclone http://hg.openjdk.java.net/jdk9/sandbox jdk9-sandbox hg tupdate -r http-client-branch Is that right? I'm not sure how one would get differences against stock jdk9. Is there a doc about how to effectively use the sandbox repository?
Re: HTTP client API
http://cr.openjdk.java.net/~chegar/docs/sandbox.html > On 23 Aug 2016, at 21:20, Martin Buchholz wrote: > > I tried this: > > (Install mercurial trees extension.) > hg tclone http://hg.openjdk.java.net/jdk9/sandbox jdk9-sandbox > hg tupdate -r http-client-branch > > Is that right? > I'm not sure how one would get differences against stock jdk9. > Is there a doc about how to effectively use the sandbox repository?
