ns explored that fixed it in the protocol handler instead.
>
> -Alan
>
> On 25/11/2019 13:31, Rob McKenna wrote:
> > Thanks Daniel,
> >
> > cc'ing core-libs-dev in case there are any objections.
> >
> > -Rob
> >
> > On 25/11/19 10:47, Da
isky.
>
> I see that your test caters for all possible setting of uses cache
> and combination of success/failure when opening the jar entry,
> so this give me confidence that the fix is working as intended.
>
> best regards,
>
> -- daniel
>
>
> On 24/11/2019 15
Hi folks,
If a FileNotFoundException is thrown when attempting to load a class
from a jar file, a reference to the open JarFile remains even after the
loader is closed. The test in the webrev demonstrates the problem by
attempting to delete the JarFile after attempting a class load.
The deletion
Thanks for the pointer to the passing host Alan. With that I was able to
track down:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=108bc4049f8ae82710aec26a92ffdb4b439c83fd
So it looks like this has recently been fixed in glibc.
-Rob
On 03/09/19 17:47, Alan Bateman wrote:
> On 03/09
Hi folks,
Assuming the premise of this bug is correct, could I get a review for
the following:
https://bugs.openjdk.java.net/browse/JDK-8219640
http://cr.openjdk.java.net/~robm/8219640/webrev.01/
Windows rejects a lookup for "127.0.0.1 test" where getaddrinfo on
non-Windows platforms resolves to
W.r.t. alternatives the HTTP serving landscape on the JVM is rich and
diverse at this point. Projects worth a look include Grizzly, Netty, Jetty,
Tomcat, Undertow, Rapidoid and the many cool frameworks build on top of
these technologies. (e.g. Jooby, SparkJava, Play to name a few)
-Rob
On 20
/2017 4:32 PM, Xuelei Fan wrote:
> >On 9/15/2017 8:22 AM, Rob McKenna wrote:
> >>This test calls close directly. (3rd last line in the stack)
> >>
> >>I believe this is the only possible stack (with the new parameter) once
> >>autoclose is set to
On 15/09/17 07:55, Xuelei Fan wrote:
> On 9/15/2017 7:41 AM, Rob McKenna wrote:
> >On 15/09/17 07:07, Xuelei Fan wrote:
> >>On 9/15/2017 7:00 AM, Rob McKenna wrote:
> >>>When we call close() on the SSLSocket that calls close() on the
> >>>underlying java So
Xuelei Fan wrote:
> On 9/15/2017 7:44 AM, Rob McKenna wrote:
> >Perhaps I'm misunderstanding you here. Can you illustrate this a bit
> >further?
> >
> The basic point is simple: removing the closing blocking even receiving
> timeout is not set.
>
> >Applicat
On 15/09/17 07:32, Xuelei Fan wrote:
> On 9/15/2017 7:16 AM, Rob McKenna wrote:
> >On 13/09/17 03:52, Xuelei Fan wrote:
> >>
> >>
> >>On 9/13/2017 8:52 AM, Rob McKenna wrote:
> >>>Hi Xuelei,
> >>>
> >>>This beh
tely)
-Rob
On 15/09/17 07:23, Xuelei Fan wrote:
> On 9/15/2017 7:07 AM, Rob McKenna wrote:
> >But they are inextricably linked regardless.
> >
> >When we close an SSLSocket it performs a readReply which is subject to
> >the read timeout. So if no read timeout is spe
On 15/09/17 07:07, Xuelei Fan wrote:
> On 9/15/2017 7:00 AM, Rob McKenna wrote:
> >When we call close() on the SSLSocket that calls close() on the
> >underlying java Socket which closes the native socket.
> >
> Sorry, I did not get the point. Please see the close() imple
On 13/09/17 03:52, Xuelei Fan wrote:
>
>
> On 9/13/2017 8:52 AM, Rob McKenna wrote:
> >Hi Xuelei,
> >
> >This behaviour is already exposed via the autoclose boolean in:
> >
> >https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFa
On 9/13/2017 8:52 AM, Rob McKenna wrote:
> >W.r.t. a separate timeout, the underlying mechanics of a close already
> >depend on the readTimeout in this situation.
> That's a concerns of mine. In order to work for your countermeasure,
> applications have to set receiving tim
gt;slow, surely there will be other issues with connecting and reading, why is
> >closing any different.
> >
> >-Chris.
> >
> >>On 13 Sep 2017, at 16:52, Rob McKenna wrote:
> >>
> >>Hi Xuelei,
> >>
> >>This behaviour is already exposed
grant
> to be gracefully.
>
> What do you think?
>
> BTW, please file a CSR as this update is introducing an external system
> property.
>
> Thanks,
> Xuelei
>
> On 9/11/2017 3:29 PM, Rob McKenna wrote:
> >Hi folks,
> >
> >In high latency envi
Hi folks,
In high latency environments a client SSLSocket with autoClose set to false
can hang indefinitely if it does not correctly recieve a close_notify
from the server.
In order to rectify this situation I would like to suggest that we
implement an integer JDK property (jdk.tls.closeRetries)
Hi folks,
Looking for a review of this simple addition to Inet4AddressImpl.c on Windows.
As per the bug report:
In the ping4() call in Inet4AddressImpl.c on Windows there is a switch
statement containing failure codes for IcmpSendEcho which correspond to well
known and expected failures for th
g has been
> > missed, should it occur.
> > So at the risk of triggering another MS curiosity, the changes look fine
>
> +1
>
> -Chris.
>
> > regards
> > Mark
> >
> > On 21/09/2016 19:45, Rob McKenna wrote:
> >> The link would be han
The link would be handy:
http://cr.openjdk.java.net/~robm/8159410/webrev.02/
-Rob
On 21/09/16 07:44, Rob McKenna wrote:
> I've updated the webrev here with the copyright year (thanks Christoph) and
> extra error codes. I overlooked the codes from the old implementation of
is. I think in case of IP_SUCCESS
> >>"RoundTripTime" is always less than timeout. I think similar changes is
> >>required in Inet6Address.c as well ? Thanks, Vyom
> >>
> >>On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote:
> >>>Hi
lse if the underline API
> IcmpSendEcho return with Status== IP_SUCESS and RoundTripTime > timeout.
>
> Vyom
>
>
> On Wednesday 21 September 2016 10:39 PM, Rob McKenna wrote:
> >Unfortunately the behaviour described is undocumented and was found the hard
> >way.
, Vyom
>
>
> On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote:
> >Hi folks,
> >
> >I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho*
> >calls can actually return a similar set of errors regardless of whether the
> >call
> Mark
>
> regards
> Mark
> On 21/09/2016 16:16, Rob McKenna wrote:
> >Hi folks,
> >
> >I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho*
> >calls can actually return a similar set of errors regardless of whether the
&g
Hi folks,
I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho*
calls can actually return a similar set of errors regardless of whether the
call itself failed or succeeded. This change checks that both the call and the
ping were successful. In addition to that it takes a nu
Hi folks,
A resource cleanup issue can cause this test to fail on windows, fix is to run
in othervm:
http://cr.openjdk.java.net/~robm/8165988/webrev.01/
-Rob
To be explicit, new webrev here:
http://cr.openjdk.java.net/~robm/6947916/webrev.03/
-Rob
On 09/09/16 07:03, Rob McKenna wrote:
> Chris just pointed out to me that the test.classes prefix on the jar path is
> unnecessary. He also mentioned that jtreg would clear up the s
Chris just pointed out to me that the test.classes prefix on the jar path is
unnecessary. He also mentioned that jtreg would clear up the scratch directory
so the deleteOnExit wouldn't be needed either.
-Rob
On 09/09/16 05:02, Rob McKenna wrote:
> Will do
>
> -Rob
Will do
-Rob
On 09/09/16 11:00, Roger Riggs wrote:
> Hi Rob,
>
> Looks ok.
>
> Its also a good practice to cleanup the file. (File.deleteOnExit).
>
> Roger
>
>
> On 9/9/2016 9:23 AM, Rob McKenna wrote:
> >Hey Chris,
> >
> >Apologies,
.java.net/~robm/6947916/webrev.02/
-Rob
On 08/09/16 08:40, Chris Hegarty wrote:
>
> > On 7 Sep 2016, at 14:17, Rob McKenna wrote:
> >
> > Hi folks,
> >
> > Looking for a review of this simple enough fix:
> >
> > http://cr.openjdk.java.ne
Hi folks,
Looking for a review of this simple enough fix:
http://cr.openjdk.java.net/~robm/6947916/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-6947916
In a nutshell, if multiple URLConnections are made to several files in a single
jar, each will use the same backing JarFile object. Unfo
Hi folks,
Looking for a review for this change.
Basically https://bugs.openjdk.java.net/browse/JDK-8135305 abandoned the old
TCP echo isReachable check in favour of Windows' ICMP calls on supported
platforms. Unfortunately it turns out that Windows 10's new App Containers
don't actually allow
that it is not reliable if the timeout is
too small? At least 1000ms timeout by default may be not acceptable in
some circumstances.
Xuelei
On 12/9/2015 12:31 AM, Rob McKenna wrote:
Testing has shown that when a timeout < 1000ms is specified the
IcmpSendEcho calls fail (apparently) randomly. O
than the specified timeout in any case:
http://cr.openjdk.java.net/~robm/8143397/webrev.02/
-Rob
On 01/12/15 14:59, Rob McKenna wrote:
It appears that there is an undocumented minimum timeout in the
IcmpSendEcho* functions. If the timeout parameter is set to a number
below this minimum timeo
It appears that there is an undocumented minimum timeout in the
IcmpSendEcho* functions. If the timeout parameter is set to a number
below this minimum timeout it is effectively ignored. Thus if you wanted
to ensure that you could ping a particular host within a certain timeout
less than the un
wxp_ping4(env, this, addrArray, timeout, ifArray, ttl)
}
regards
Mark
On 25/11/2015 15:32, Seán Coffey wrote:
Looks ok to me Rob and provides a re-introduction of the old
Java_java_net_Inet4AddressImpl_isReachable0 function for XP systems
where necessary. Reviewed.
Approved for
forgot to cc net-dev
-Rob
On 24/11/15 16:37, Rob McKenna wrote:
Hi folks,
The recently updated ICMP (8133015) code fails on Windows XP due to a
missing api. This fix allows XP to fall back to the old tcp based method:
https://bugs.openjdk.java.net/browse/JDK-8141260
http
?
regards
Mark
On 24/09/2015 15:45, Rob McKenna wrote:
Please ignore the formatting errors. Thats either a problem with hg
diff or webrev, but its fixed in the repo.
-Rob
On 24/09/15 15:43, Rob McKenna wrote:
Hi folks,
The recent change to isReachable (8133015:
InetAddress.isReachable(t
Hi folks,
The recent change to isReachable (8133015:
InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6
- http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59ff6cd9535d) neglected
to take the specified interface into account for ipv4.
This change ensures that isReachable ret
Please ignore the formatting errors. Thats either a problem with hg diff
or webrev, but its fixed in the repo.
-Rob
On 24/09/15 15:43, Rob McKenna wrote:
Hi folks,
The recent change to isReachable (8133015:
InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6
Hi folks, looking for a review for this simple change.
The change for https://bugs.openjdk.java.net/browse/JDK-8040747
initialised each octet to 0. This meant that ... was translated to
0.0.0.0 before checking the validity of the address.
This small change remedies that.
http://cr.openjdk.ja
Hi folks,
Upon investigating what turned out to be a network traffic filtering
problem it was noticed that Windows InetAddress.isReachable() leverages
TCP to detect other hosts on the network. Since new APIs for using ICMP
have been implemented in Windows 2000 it could be helpful to support th
Thanks Michael,
A test would be pretty tricky given the configuration specific nature of
the problem. (Mac, VPN etc.)
-Rob
On 03/06/15 16:22, Michael McMahon wrote:
Seems reasonable Rob. I guess a test isn't feasible?
Michael.
On 03/06/15 14:25, Rob McKenna wrote:
Hi
Hi folks,
7180557 used getifaddrs as a way of determining the local hosts ip
address on Mac OSX in order to fix a problem with OSX's naming system.
When fixing this we decided to place that call before the call to
getaddrinfo thus taking the naming system out of the equation.
Unfortunately w
Adding bug id to subject for reference.
-Rob
On 22/05/15 16:05, Rob McKenna wrote:
Hi Brian,
By coincidence I just started looking at this today myself.
We have an existing bug filed for this issue:
https://bugs.openjdk.java.net/browse/JDK-8080819
The diagnosis looks good
Hi Brian,
By coincidence I just started looking at this today myself.
We have an existing bug filed for this issue:
https://bugs.openjdk.java.net/browse/JDK-8080819
The diagnosis looks good.
-Rob
On 22/05/15 07:56, Brian Toal wrote:
The fix for https://bugs.openjdk.java.net/browse/
the same change.
Michael
On 20/05/15 13:24, Rob McKenna wrote:
Hi folks,
Looking for a review of this webrev:
http://cr.openjdk.java.net/~robm/8077155/webrev.01/
Basically the subjects credentials are not available to
HttpURLConnection.getInputStream0 since it now runs in a doPrivileged
block
Hi folks,
Looking for a review of this webrev:
http://cr.openjdk.java.net/~robm/8077155/webrev.01/
Basically the subjects credentials are not available to
HttpURLConnection.getInputStream0 since it now runs in a doPrivileged
block. Changing that to doPrivilegedWithCombiner allows getInputStre
Pressed send a little too early. This test was added by:
8067846: (sctp) InternalError when receiving SendFailedNotification
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b10dc4dc6903
-Rob
On 18/03/15 23:27, Rob McKenna wrote:
Hi folks,
Mistakenly neglected to exclude Solaris from testing
Hi folks,
Mistakenly neglected to exclude Solaris from testing:
http://cr.openjdk.java.net/~robm/8075039/webrev.01/
-Rob
This is a fix to a possible race in the current sctp code. In a nutshell
the conditional only checks that isaCls is not null. However if isaCls
is set by one thread and that thread is interrupted before setting
isaCtrID, the interrupting thread will falsely assume that isaCtrID has
been set.
Hi folks,
Very simple fix to allow FtpURLConnection connect without a password in
the url. (i.e. ftp://user@server/ as opposed to the current
ftp://user:@server)
http://cr.openjdk.java.net/~robm/8031435/webrev.01/
-Rob
Changeset: da4b0962ad11
Author:robm
Date: 2014-02-10 14:35 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11
7152892: some jtreg tests fail with permission denied
Reviewed-by: coffeys
! test/java/lang/ClassLoader/Assert.sh
! test/java/rmi/registry/readTest/readTest
Changeset: 72ea199e3e1b
Author:robm
Date: 2013-12-05 16:19 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72ea199e3e1b
8029525: java/lang/ProcessBuilder/Basic.java fails intermittently
Reviewed-by: alanb, chegar
Contributed-by: roger.ri...@oracle.com
! test/java/lang/Process
Changeset: 89fccc5a7469
Author:martin
Date: 2013-11-21 16:06 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89fccc5a7469
6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
Reviewed-by: alanb
! test/java/lang/ProcessBuilder/Basic.java
Changeset: 63b696dafc8a
Author:robm
Date: 2013-11-19 15:36 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63b696dafc8a
8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
Reviewed-by: chegar, alanb
! test/java/lang/ProcessBuilder/Basic.java
Changeset: e2ec05b2ed94
Author:igerasim
Date: 2013-10-23 15:37 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2ec05b2ed94
8024521: (process) Async close issues with Process InputStream
Reviewed-by: psandoz, martin, alanb, robm
! src/solaris/classes/java/lang/UNIXProcess.jav
only P1-3 bugs are being
accepted [1]. I see this is a P4. Should it be deferred to the next
available minor update, or do you think it warrants being fixed in jdk8.
-Chris.
[1] http://openjdk.java.net/projects/jdk8/milestones#Rampdown_start
On 18/10/2013 18:36, Rob McKenna wrote:
Hi
Hi folks,
Simple enough change here. As per the description HttpCookie.setMaxAge
will set any arbitrary negative value, while we only check for
MAX_AGE_UNSPECIFIED to determine whether a cookies max age has been
specified or not. This fix sets maxAge to MAX_AGE_UNSPECIFIED if the
setMaxAge(ex
Changeset: 8d1d5a5aeb41
Author:robm
Date: 2013-10-18 16:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d1d5a5aeb41
8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log
open in fastdebug builds
Reviewed-by: alanb
Contributed-by: pavel.pune...@ora
Changeset: d8eec0e3a023
Author:robm
Date: 2013-10-16 15:06 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8eec0e3a023
8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx)
Reviewed-by: chegar, alanb
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/
Updated webrev at:
http://cr.openjdk.java.net/~robm/8026245/webrev.02/
-Rob
On 15/10/13 15:31, Rob McKenna wrote:
Caught me. I've just updated the tests in place actually. Another jprt
job is in progress. (I've just checked preferIPv4 manually and it passes)
I'll add a
Caught me. I've just updated the tests in place actually. Another jprt
job is in progress. (I've just checked preferIPv4 manually and it passes)
I'll add a new webrev with your other suggestions.
-Rob
On 15/10/13 15:23, Alan Bateman wrote:
On 15/10/2013 15:05, Rob McK
Hi folks,
Looking for a review for the following:
http://cr.openjdk.java.net/~robm/8026245/webrev.01/
It seems there were a number of issues with the original fix for
7180557. This patch resolves those:
- No existing net tests exercised the ipv4 only codepath
- the extern to lookupIfLocalhos
Changeset: f1e31376f419
Author:robm
Date: 2013-10-09 00:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419
7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX
webbugs
Reviewed-by: chegar, dsamersoff
! src/solaris/native/java/net/Inet4
Heh, you just beat me to the punch.
-Rob
On 07/10/13 17:34, Dmitry Samersoff wrote:
Rob,
Existing code uses if (JVM_GetHostName(myhostname, NI_MAXHOST)) so I
withdraw my last comments. Please, don't change it!!!
-Dmitry
On 2013-10-07 20:30, Rob McKenna wrote:
Thanks Dmitry!
cking, explicit == -1 would be better here.
Actually, can you tell me why you'd rather not
include ipv6 loopbacks at all?
If interface don't have ipv6 address but we have ipv6 loopback it most
likely means that ipv6 is not functioning properly.
-Dmitry
On 2013-10-04 19:03, Rob McK
robably you should throw
JNU_ThrowOutOfMemoryError(env, "Object allocation failed");
-Dmitry
On 2013-09-20 18:58, Rob McKenna wrote:
After a brief discussion with Chris, we decided to revert the position
of the call to lookupIfLocalAddrs so as to give the local host primacy
over DNS
After a brief discussion with Chris, we decided to revert the position
of the call to lookupIfLocalAddrs so as to give the local host primacy
over DNS.
Latest (and hopefully last) webrev here:
http://cr.openjdk.java.net/~robm/7180557/webrev.03/
-Rob
On 14/09/13 00:00, Rob McKenna wrote
call to getifaddrs only occurs if getaddrinfo
fails.
-Rob
On 13/09/13 20:28, Bernd Eckenfels wrote:
Am 13.09.2013, 19:32 Uhr, schrieb Rob McKenna :
W.r.t. the use of AI_CANONNAME, this doesn't actually make a
difference in the context of this fix, but is definitely something
that
2013-09-03 19:18, Rob McKenna wrote:
Hi folks,
Mac seems to have trouble looking up local hostnames using getaddrinfo
unless a domain is set. The solution is to add a check with getifaddrs .
This fix replaces a usage of _ALLBSD_SOURCE with MACOSX. I haven't seen
a canonical answer on whether
Thanks for the comments folks. Chris, I like the idea of moving this
check below the GAI call. Dmitry, that loop is indeed a bit of a code
smell. I'll take care of it. Bernd / Dmitry, thanks for the notes on
AI_CANONNAME. I'll adjust the code and get some testing done then report
back!
I've k
cal machines IP information. Did that discussion lead to getifaddrs?
-Chris.
On 03/09/2013 16:18, Rob McKenna wrote:
Hi folks,
Mac seems to have trouble looking up local hostnames using getaddrinfo
unless a domain is set. The solution is to add a check with getifaddrs .
This fix repl
Hi folks,
Mac seems to have trouble looking up local hostnames using getaddrinfo
unless a domain is set. The solution is to add a check with getifaddrs .
This fix replaces a usage of _ALLBSD_SOURCE with MACOSX. I haven't seen
a canonical answer on whether this is the way to go so I figured tr
Changeset: a4b0be7341ef
Author:robm
Date: 2013-08-13 19:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4b0be7341ef
5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Reviewed-by: alanb, dholmes, martin, erikj, coffeys
! make/java/java/Exportedf
Changeset: 607fa1ff3de2
Author:bpb
Date: 2013-07-09 11:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/607fa1ff3de2
6178739: (fmt) Formatter.format("%0.4f\n", 56789.456789) generates
MissingFormatWidthException
Summary: Change the field width specification to require a pos
Glad to hear you got to the bottom of it.
-Rob
On 08/07/13 23:22, Bernd Eckenfels wrote:
Hello,
we found a cause for the leak, we did not use the latest xnio-nio
release. Looking at the NioTcpChannel code I guess that for example
this commit could fix a potential problem (we shutdown r+w
Changeset: 2707f600a096
Author:robm
Date: 2013-06-15 09:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2707f600a096
8016701: JAXP Build failure
Reviewed-by: darcy, wetmore, alanb, chegar
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
Changeset: d28f802ce914
Author:robm
Date: 2013-06-06 22:22 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d28f802ce914
8016063: getFinalAttributes should use FindClose
Reviewed-by: alanb
! src/windows/native/java/io/WinNTFileSystem_md.c
Changeset: b16a8b4ae6b4
Author:robm
Date: 2013-05-28 16:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16a8b4ae6b4
7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys
Reviewed-by: alanb
! src/windows/native/java/io/WinNTFileSystem_md.c
! test/ja
ards
Anthony
Op 27/03/2013 18:25, Rob McKenna schreef:
HI Matthew,
On the face of it this makes sense. I don't have time to dig into it
this week, but I'll get stuck into it next week and get a fix together.
-Rob
On 27/03/13 00:42, Matthew Hall wrote:
Forgot to inclu
HI Matthew,
On the face of it this makes sense. I don't have time to dig into it
this week, but I'll get stuck into it next week and get a fix together.
-Rob
On 27/03/13 00:42, Matthew Hall wrote:
Forgot to include, offending code in HttpURLConnection:
if (!method.equals("PUT") && (post
Changeset: 3f8fbb0ab155
Author:robm
Date: 2013-03-21 17:33 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f8fbb0ab155
8009251: Add proxy handling and keep-alive fixes to jsse
Reviewed-by: chegar
! src/share/classes/sun/net/www/http/HttpClient.java
!
src/share/classes/sun/n
Changeset: f5c85c0a9af0
Author:robm
Date: 2013-03-14 00:21 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5c85c0a9af0
8009650: HttpClient available() check throws SocketException when connection
has been closed
Reviewed-by: chegar, khazra, dsamersoff
Contributed-by: sdoug..
On 13/03/2013 12:53, Dmitry Samersoff wrote:
Rob,
Looks good for me.
-Dmitry
On 2013-03-13 04:35, Rob McKenna wrote:
Hi folks,
New webrev at:
http://cr.openjdk.java.net/~robm/8009650/webrev.02/
Apologies for the delay.
-Rob
On 07/03/13 23:19, Rob McKenna wrote:
Ah, I see what y
Hi folks,
New webrev at:
http://cr.openjdk.java.net/~robm/8009650/webrev.02/
Apologies for the delay.
-Rob
On 07/03/13 23:19, Rob McKenna wrote:
Ah, I see what you mean. Can do.
-Rob
On 07/03/13 23:13, Dmitry Samersoff wrote:
Rob,
Sorry for not being clean enough. We have
r readable if we can put it to some common place.
-Dmitry
On 2013-03-08 02:31, Rob McKenna wrote:
Hi Dmitry,
I'm not 100% sure what you mean by duplication, the exceptions and their
messages are distinct. I think it would be best to keep it that way.
-Rob
On 07/03/13 22:00, Dmitry
int r;
try {
...
} catch (SocketException e) {
// Comments goes here
r = -1
}
if (r == -1){
if (logger. ...
available = false;
}
return available;
-Dmitry
On 2013-03-07 20:18, Rob McKenna wrote:
Hi folks,
This is a slight alteration of th
I've fleshed out the bug report a little to make that clearer, sorry Kurchi!
Also, I'll add a testcase to this review soon.
-Rob
On 07/03/13 16:51, Kurchi Subhra Hazra wrote:
I am wondering why do you need two try-catch blocks here.
- Kurchi
On 3/7/13 8:18 AM, Rob McKenna
The outer try/catch is meant to catch potential exceptions originating
from the inner try/finally. (from setSoTimeout)
-Rob
On 07/03/13 16:51, Kurchi Subhra Hazra wrote:
I am wondering why do you need two try-catch blocks here.
- Kurchi
On 3/7/13 8:18 AM, Rob McKenna wrote:
Hi folks
Hi folks,
This is a slight alteration of the fix contributed by Stuart Douglas.
This fix deals with a SocketException caused by getSoTimeout() on a
closed connection.
http://cr.openjdk.java.net/~robm/8009650/webrev.01/
-Rob
ssage saying it was awaiting
moderator approval as I am not a member).
Stuart
Rob McKenna wrote:
Thanks for this Stuart, do you happen to have a reference to the bug you
filed on the Oracle site?
-Rob
On 02/03/13 08:55, Stuart Douglas wrote:
Seeing as the patch appears to have been stripped
garty"
To: "Stuart Douglas"
Cc: "Alessio Soldano" , "OpenJDK Network Dev list"
, "Rob McKenna"
Sent: Saturday, 2 March, 2013 7:37:30 PM
Subject: Re: OpenJDK HTTP Client Bug
[bcc'ing off jdk7-...@openjdk.java.net, and including
net-dev@openjdk.java.net]
Hi folks,
I'd like to port some changes around proxy handling, keep alive and
tunnelling to the HttpsClient. These should have been done along with
the HttpClient. Webrev is at:
http://cr.openjdk.java.net/~robm/8009251/webrev.01/
related issues:
https://jbs.oracle.com/bugs/browse/JDK-719921
Changeset: 44d6cabc9a3f
Author:robm
Date: 2013-01-15 19:58 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44d6cabc9a3f
8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently
Reviewed-by: alanb, martin, dholmes
! test/java/lang/ProcessBuilder/Basic.java
Changeset: 68374c6e65c1
Author:robm
Date: 2012-12-12 15:57 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68374c6e65c1
8004337: java/sql tests aren't run in test/Makefile
Reviewed-by: lancea, alanb
! test/Makefile
..the url would be helpful:
http://cr.openjdk.java.net/~robm/8000525/webrev.02/
-Rob
On 12/12/12 15:43, Rob McKenna wrote:
Hi Chris,
I guess I figured if the parse failed the cal.set wouldn't happen.
Still, no harm in moving the 1970 into the loop on the off chance
something else
Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop?
The test can simply throw Exception, rather can catching.
Otherwise, looks fine to me.
-Crhis.
On 06/12/2012 21:19, Rob McKenna wrote:
Hi folks,
According to HttpCookie.java:
"""
There are 3 http cookie
Changeset: 40311b5f478f
Author:robm
Date: 2012-11-28 00:47 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40311b5f478f
8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests
Reviewed-by: chegar
+ test/java/net/ResponseCache/Test.java
+ test/java/net/Socket/
Hi folks,
Looking to move a pair of tests into the open repo:
http://cr.openjdk.java.net/~robm/8003597/webrev.01/
Thanks,
-Rob
1 - 100 of 119 matches
Mail list logo
