Changeset: f642c9ec81a0
Author:robm
Date: 2010-11-15 10:46 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/f642c9ec81a0
6277781: Serialization of Enums over IIOP is broke.
Summary: Reviewed by Ken Cavanaugh
Reviewed-by: coffeys
!
Hi folks,
A typo in the MacOSX work led to a regression in b11 of 7u4. Specifically:
http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/diff/5cca2f1a37da/src/solaris/native/java/net/Inet6AddressImpl.c
As per the bug report the in the 2nd #if macro meant that this
condition was ignored and the
Changeset: b26c04717735
Author:robm
Date: 2012-05-07 13:34 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b26c04717735
7166687: InetAddress.getLocalHost().getHostName() returns FQDN
Reviewed-by: chegar
! src/solaris/native/java/net/Inet6AddressImpl.c
Changeset: 178c480998b1
Author:robm
Date: 2012-05-17 22:42 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/178c480998b1
7168110: Misleading jstack error message
Reviewed-by: alanb, dsamersoff
! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c
Changeset: a7895dc61088
Author:robm
Date: 2012-06-08 18:23 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7895dc61088
7161881: (dc) DatagramChannel.bind(null) fails if IPv4 socket and running with
preferIPv6Addresses=true
Reviewed-by: alanb, chegar
!
Changeset: ff0da4ea08a2
Author:robm
Date: 2012-06-26 13:27 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff0da4ea08a2
4244896: (process) Provide System.getPid(), System.killProcess(String pid)
Reviewed-by: alanb
! src/share/classes/java/lang/Process.java
!
Changeset: ecc5dd3790a1
Author:robm
Date: 2012-07-02 19:32 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecc5dd3790a1
7174887: Deadlock in jndi ldap connection cleanup
Reviewed-by: xuelei
! src/share/classes/com/sun/jndi/ldap/Connection.java
!
Changeset: 516e0c884af2
Author:robm
Date: 2012-07-09 22:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/516e0c884af2
7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is
misspelled
Reviewed-by: dholmes, chegar
!
Changeset: da14e2c90bcb
Author:robm
Date: 2012-08-15 22:46 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb
6931128: (spec) File attribute tests fail when run as root.
Reviewed-by: alanb
! src/share/classes/java/io/File.java
! test/java/io/File/Basic.java
!
Hi folks,
Looking for a review for:
7199219: Proxy-Connection headers set incorrectly when a HttpClient is
retrieved from the Keep Alive Cache
http://cr.openjdk.java.net/~robm/7199219/webrev.01/
http://cr.openjdk.java.net/%7Erobm/7199219/webrev.01/
Basically we never set the correct
Hi folks,
This one is connected to 7199219 and has an intersecting change in that
we're similarly passing the httpuc from HttpURLConnection. Despite the
intersection I've filed these as two separate issues because a) they are
and b) I wouldn't like one to be held up by the other.
The
Changeset: 11a5da68673c
Author:robm
Date: 2012-09-27 22:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11a5da68673c
7199862: Make sure that a connection is still alive when retrieved from
KeepAliveCache in certain cases
Reviewed-by: chegar
!
Changeset: b3c7a3138c5d
Author:robm
Date: 2012-09-28 04:39 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3c7a3138c5d
7199219: Proxy-Connection headers set incorrectly when a HttpClient is
retrieved from the Keep Alive Cache
Reviewed-by: chegar
!
Hi folks,
Lumping these backports together.
7199219: Proxy-Connection headers set incorrectly when a HttpClient is
retrieved from the Keep Alive Cache
7199862: Make sure that a connection is still alive when retrieved from
KeepAliveCache in certain cases
Webrevs at:
Changeset: bba370caafad
Author:robm
Date: 2012-10-04 19:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba370caafad
7184932: Remove the temporary Selector usage in the NIO socket adapters
Reviewed-by: alanb
! make/java/nio/mapfile-bsd
! make/java/nio/mapfile-linux
!
Changeset: 7c2f5e52863c
Author:robm
Date: 2012-10-11 18:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c2f5e52863c
7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently
[sol]
Reviewed-by: alanb, martin, dholmes
!
Changeset: c0736b62160e
Author:robm
Date: 2012-10-15 22:34 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0736b62160e
8000487: Java JNDI connection library on ldap conn is not honoring configured
timeout
Reviewed-by: vinnie
!
Hi folks,
Looking to move a pair of tests into the open repo:
http://cr.openjdk.java.net/~robm/8003597/webrev.01/
Thanks,
-Rob
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
+
'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 specifications:
Netscape draft
RFC 2109
..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 goes
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
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
!
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:
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 here
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
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 wrote:
Hi
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 the fix
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 Samersoff wrote:
Rob
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:
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
!
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) (poster
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
!
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
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
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
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
!
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
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 replaces a usage
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
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 this is the way
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 rob.mcke...@oracle.com:
W.r.t. the use of AI_CANONNAME, this doesn't actually make a
difference in the context of this fix, but is definitely
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
-ifa_next;
continue; // redundant just for readability
}
}
ll.244
I'm not sure it's good to return partially complete array in case of
object allocation fail. Probably you should throw
JNU_ThrowOutOfMemoryError(env, Object allocation failed);
-Dmitry
On 2013-09-20 18:58, Rob McKenna wrote
, 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 McKenna wrote:
Hi
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! I'll
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:
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
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 folks
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
!
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: 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: 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
!
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
!
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
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.
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
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
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
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
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.
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
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
gards
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(tmout)
han 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 time
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
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 jdk8u
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
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
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
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.
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,
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
>
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
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 itsel
ards
> 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
> >call itself failed or s
ains this. 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 folk
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
>
handling will inform if something 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:
>
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
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 environments a client SS
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
ow, 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 <rob.mcke...@oracle.com> wrote:
> >>
> >>Hi Xuelei,
> >>
> >>This
:
> 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 t
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 specified, the cal
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
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.
>
> >Applications alread
/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 Socket which
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
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 false. If au
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)
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
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
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
> 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:33, Rob McKenn
1 - 100 of 102 matches
Mail list logo
