Looks good Kiran. I'll sponsor this for you.
regards,
Sean.
On 08/10/2019 17:19, Kiran Ravikumar wrote:
Hi Guys,
Could you please review this minor fix:
Bug :https://bugs.openjdk.java.net/browse/JDK-8214560
Webrev :https://cr.openjdk.java.net/~coffeys/webrev.8214560/webrev/
Looks fine to me.
Regards,
Sean.
On 31/05/19 11:58, Chris Hegarty wrote:
The implementation of java.net.JarURLConnection has a private String,
`entryName`, that is used to hold the optional jar file entry name. If
the JAR file URL corresponding to the JarURLConnection points to a JAR
file and
otocol);
}
Thanks!
/Claes
On 2019-05-02 12:33, Seán Coffey wrote:
with webrev:
https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
regards,
Sean.
On 02/05/2019 11:00, Seán Coffey wrote:
Been thinking a bit more about this one.
Given that only initialization code will tr
with webrev: https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
regards,
Sean.
On 02/05/2019 11:00, Seán Coffey wrote:
Been thinking a bit more about this one.
Given that only initialization code will traverse through the "if
(!isOverrideable(protocol))" check, I think
er we make the first handers.get call in
getURLStreamHandler(String protocol)
http://gbr10227.uk.oracle.com/html/ws/jdk-jdk/open/webrev.8217364.02/webrev/
regards,
Sean.
On 30/04/2019 18:19, Seán Coffey wrote:
Looking to correct an issue that arose during the JDK-8213942 fix.
https://bugs.openjd
Looking to correct an issue that arose during the JDK-8213942 fix.
https://bugs.openjdk.java.net/browse/JDK-8217364
https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
regards,
Sean.
Looks fine to me also!
Regards,
Sean.
On 14/03/19 19:41, Langer, Christoph wrote:
Looks good, +1
/Christoph
*From:*net-dev *On Behalf Of *Chris
Hegarty
*Sent:* Donnerstag, 14. März 2019 17:47
*To:* net-dev
*Subject:* RFR 8179549: Typo in network properties documentation
Trivial typo
On 26/11/18 12:59, Pavel Rappo wrote:
On 26 Nov 2018, at 12:12, Seán Coffey wrote:
JDK-8213942 synchronization fix can be improved
Looks like a soft language for what actually is a race condition. I wonder at
what point should we just rewrite the thing as Alan mentioned using "
JDK-8213942 synchronization fix can be improved. Details in bug report.
https://bugs.openjdk.java.net/browse/JDK-8214295
http://cr.openjdk.java.net/~coffeys/webrev.8214295/webrev/
--
Regards,
Sean.
Thanks to all for the feedback. It makes sense to reduce the scope of
the lock where possible.
I've updated the webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8213942.v2/webrev/
Regards,
Sean.
On 20/11/18 20:59, Chris Hegarty wrote:
Sean,
On 20 Nov 2018, at 17:55, Seán Coffey wrote
On 20/11/2018 19:07, Alan Bateman wrote:
On 20/11/2018 17:55, Seán Coffey wrote:
A race condition recently reported by the WLS team. Access to the
handlers Hashtable and the factory should be made while holding the
streamHandlerLock lock.
WLS team also made efforts to create a reproducer
A race condition recently reported by the WLS team. Access to the
handlers Hashtable and the factory should be made while holding the
streamHandlerLock lock.
WLS team also made efforts to create a reproducer. I've modified to
jtreg format and reduced it down further for unit testing.
As someone who works with alot of log files, I'd like to chime in and
support Steven's end goal. Looking at a "Connection refused" error in
the middle of a log file that possibly extends to millions of lines is
near useless. In the era of cloud compute, diagnosing network issues is
sure to
Looking to backport this to jdk8u-dev. There was a minor tweak in the
testcase around how the interfaces are streamed. As a result, I'm
carrying out a code review for the backport. Dropped use of
"NetworkInterface.networkInterfaces();"
Presume it's ok :
concurrent Java coding :) Well
done! +1
Best regards
Christoph
-Original Message-
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: Freitag, 23. Juni 2017 15:28
To: Seán Coffey <sean.cof...@oracle.com>; Langer, Christoph
<christoph.lan...@sap.com>
Cc: net-
Java coding :) Well done! +1
Best regards
Christoph
-Original Message-
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: Freitag, 23. Juni 2017 15:28
To: Seán Coffey <sean.cof...@oracle.com>; Langer, Christoph
<christoph.lan...@sap.com>
Cc: net-dev <net-dev@o
, e.g. when it comes to an
exception, the thread name could be mentioned, too.
Best regards
Christoph
-Original Message-
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
Seán Coffey
Sent: Donnerstag, 22. Juni 2017 20:17
To: Vyom Tewari <vyom.tew...@oracle.com>; n
e cscotun0- Thread3
Testing: cscotun0
Thanks,
Vyom
On Thursday 22 June 2017 09:59 PM, Seán Coffey wrote:
JDK 10 fix required to correct a race issue in NetworkInterface. I
don't believe the ifreq struct needs to be static in any case. New
auto unit testcase also. I propose to skip this fix for JDK
JDK 10 fix required to correct a race issue in NetworkInterface. I don't
believe the ifreq struct needs to be static in any case. New auto unit
testcase also. I propose to skip this fix for JDK 9 and fix in an update
release for that family. I also plan to port this to jdk8u-dev.
Looking for a simple review. Test should be run in ovm mode :
https://bugs.openjdk.java.net/browse/JDK-8177144
diff --git a/test/sun/net/www/http/HttpClient/B8025710.java
b/test/sun/net/www/http/HttpClient/B8025710.java
--- a/test/sun/net/www/http/HttpClient/B8025710.java
+++
spotted an interesting blog on the MSDN timeout issue here :
https://www.frameflow.com/ping-utility-flaw-in-windows-api-creating-false-timeouts/
Regards,
Sean.
On 21/09/16 17:42, Mark Sheppard wrote:
the IcmpSendEcho series of calls come with some idiosyncrasies in that
there is a minimum
Nice clean up Chris. Looks fine.
Regards,
Sean.
On 09/06/16 20:49, Chris Hegarty wrote:
This test has been seen to fail intermittently. There is an assumption in the
test that the client-side will fill the outgoing TCP buffer by writing 1
megabyte
of data, allowing for the server-side to
Looks fine to me also Chris.
Regards,
Sean.
On 30/05/2016 22:52, Mark Sheppard wrote:
Hi Chris,
this looks good ... so the server now listens on wildcard and the
client uses IPv6 loopback as the destination address.
The use of NO_PROXY, is good. I wouldn't have thought of that, and in
webrev updated in place with suggestion from Pavel (off thread) to place
quotes around the problem values.
Regards,
Sean.
On 20/04/16 14:33, Seán Coffey wrote:
Looking for a review for these simple changes. URLPermissions is a
class introduced for JDK 8. Exception messaging can be improved
Looking for a review for these simple changes. URLPermissions is a class
introduced for JDK 8. Exception messaging can be improved to capture
context.
https://bugs.openjdk.java.net/browse/JDK-8071125
http://cr.openjdk.java.net/~coffeys/webrev.8071125/webrev/
--
Regards,
Sean.
On 29/03/2016 20:16, Andrej Golovnin wrote:
177 throw new
IllegalArgumentException(String.valueOf(n));
>>
>>Could you please provide a better message for exception here?
>
>What would the purpose be? It's an internal implementation detail. If this
>exception is
One comment on the supportability side from me :
java/net/AbstractPlainDatagramSocketImpl.java
> + case SO_REUSEPORT:
> + if (o == null || !(o instanceof Boolean)) {
> + throw new SocketException("bad argument for
SO_REUSEPORT");
> + }
> +
wrote:
Hi Sean,
Thank you. I have updated copyright year to the earlier patch and added a
simple test case to cover this bug.
Please review the updated Webrev:
http://cr.openjdk.java.net/~rpatil/8135259/webrev.01/
Regards,
Ramanand.
-Original Message-
From: Seán Coffey
Sent: Wednesday
The changes look fine to me also Chris.
Regards,
Sean.
On 22/01/16 14:49, Chris Hegarty wrote:
On 21/01/16 22:55, Felix Yang wrote:
Hi Chris,
your fix is cool. I will assign the bug to you:)
a comment on this fix. The test changed system SecurityManager and
it is not executed with
Hey Vinnie,
question on SSLParameters.setApplicationProtocols(String[] protocols) method
What happens if you pass an empty array into this method. Shouldn't it
throw an IllegalArgumentException ?
In ALPNExtension.java :
+if (listLength < 2 || listLength + 2 != len) {
+
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-dev also.
Regards,
Sean.
On 25/11/15 14:00, Rob McKenna wrote:
forgot to cc net-dev
-Rob
On 24/11/15 16:37,
Thanks for handling Artem. I'll leave the main review to someone more
knowledgeable with http authentication schemes but can I suggest that
your print the AuthenticationHeader.authPref string out with the
"Negotiate process failed, fallback" logger message. It's a useful
variable to capture.
These changes look fine to me Ivan. Approved for jdk8u-dev.
Regards,
Sean.
On 09/09/2015 17:39, Ivan Gerasimov wrote:
Hello!
I'd like to backport this recent fix from jdk9 to jdk8u-dev.
The fix applies *almost* cleanly after unshuffling.
The only manual editing I had to do was creating
Michael,
I'd like to backport this fix to JDK 8u60. The port is pretty much the
same as 9 except for modular path changes. The OptionsTest modified in
jdk9 fix does not exist in jdk8u (test was for new API in JDK 9)
As a result, I was able to modify the jdk/net/Sockets/Test.java test
setsockopt(4, SOL_IP, IP_TOS, [128], 4) = 0
Note :
0x43 == IPV6_TCLASS 67
0x21 == IPV6_FLOWINFO_SEND 33
latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.tos-may22/webrev/
Regards,
Sean.
On 25/03/15 17:21, Seán Coffey wrote:
I didn't see any review on this request yet. I've modified
It looks like setting and getting the IP_TOS values on the java.net
Sockets is currently broken for some scenarios. It's not possible to set
the value on a ServerSocket via the jdk.net.Sockets.setOption API. See
below for a webrev I'm proposing. It basically makes best efforts to set
the
This issue relates to another bug that I own : JDK-8062305
It seems to be an area that causes alot of issue (for plugin mainly) and
the suggestion from Chris in 7178362 bug report to return a direct
connection type for bad ProxySelector implementations seems appropriate.
webrev :
for proxy:
+ p);
// Use getHostString() to avoid reverse lookups
server = ((InetSocketAddress) p.address()).getHostString();
serverPort = ((InetSocketAddress) p.address()).getPort();
-Chris.
On 24 Feb 2015, at 17:24, Seán Coffey sean.cof
Thanks all - Agreed changes pushed to 7u85 and I'll make a request to
see if we can include this in 7u80 code base.
regards,
Sean.
On 30/01/2015 16:00, Alan Bateman wrote:
On 30/01/2015 12:18, Seán Coffey wrote:
Alan,
hadn't spotted the race issue. I guess we could delay setting
unless I hear objections.
regards,
Sean.
On 29/01/2015 17:31, Alan Bateman wrote:
On 26/01/2015 13:48, Seán Coffey wrote:
Valeriy,
those changes look fine to me and I've verified that they run through
testing fine also. webrev here for reference :
http://cr.openjdk.java.net/~coffeys/webrev
?
Best regards,
Valeriy Kopylov,
Software Engineer,
Akvelon,
Skype: Valeriy.Kopylov
*From:*Martin Sawicki (MS OPEN TECH)
*Sent:* Saturday, January 24, 2015 03:21
*To:* Seán Coffey; Valery Kopylov (Akvelon); jdk7u-...@openjdk.java.net
*Cc:* Kirk Shoop (MS OPEN TECH); OpenJDK Network Dev list
Konstantin,
can you hold off pushing this fix to jdk8u for the moment ? It's a P4
and could have behavioural consequences (something we try and avoid in
update releases). I see JDK-8071458 was logged to track IPv6 scope
specifications. Let's see how this soaks into JDK 9 over coming days and
://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/src/windows/native/sun/nio/ch/Net.c.cdiff.html
Good to push ? I'll try and get this into 7u80 but can't guarantee that
now given that we've entered the rampdown/stabilization phase.
regards,
Sean.
On 15/01/15 12:09, Seán Coffey wrote:
Valeriy,
I used
Looking for a review around this issue that came in as a reported
performance regression in NTLM proxy authentication. It turned out that
HttpsClients were being discarded after Proxy SocketAddress equality
tests failed. Lack of caching is expensive in terms for performance for
TLS and
Following bugs need to be backported to jdk7u-dev to correct issues
where SO_FLOW_SLA availability might not be available or where
sufficient permissions are not in place.
https://jbs.oracle.com/bugs/browse/JDK-8046588
https://jbs.oracle.com/bugs/browse/JDK-8047187
Testcase changes keep to
I'd like to backport these fixes into the jdk7u-dev codeline. They're
already in jdk8u-dev.
https://bugs.openjdk.java.net/browse/JDK-8032808 - SO_FLOW_SLA support
for solaris
https://bugs.openjdk.java.net/browse/JDK-8047186 - Exception handling
change linked to above
was made to know about the new NetworkPermission class. I don't think
we backported it to
8 even. But, for completeness sake we might want to backport it to
both of these releases
at some point in the future.
Michael
On 22/08/14 16:24, Seán Coffey wrote:
I'd like to backport these fixes
Just on a technical point Michael - these classes came in for JDK 8u20.
@since 1.8 tag might be confusing. I'd suggest that we just omit the
@since tags for 8u20. (can be documented in release notes)
Maybe we should seek clarification around whether a tag like @since
1.8.0_20 could be used.
thanks Michael. Will update copyrights before pushing.
regards,
Sean.
On 26/02/14 16:12, Michael McMahon wrote:
Looks good to me. The copyright date on the new src/macosx files could
be updated though.
Thanks
Michael
On 26/02/14 15:45, Seán Coffey wrote:
Looking to backport this one
Taken feedback on board. New webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8024952.2/webrev/
I've managed to get confirmation from original submitter that this works
ok for them.
regards,
Sean.
On 20/09/2013 11:29, Seán Coffey wrote:
Dmitry,
You're right. I was cautious in moving
On 01/10/2013 13:37, Daniel Fuchs wrote:
Hi Seán,
This looks simpler and better :-)
However I wonder, do you still need to catch NPE
in CustomSocketImplFactory.main ?
Daniel,
Since I'm only creating a dummy socketImpl to test the
classcastexception, no real networking stack is in place
get this corrected and tested.
Thanks for pointers.
Sean.
On 20/09/13 10:20, Dmitry Samersoff wrote:
Sean,
It might be possible to set s.fd to delegate.fd before call to
impl.accept and therefore merge if instanceOf block.
-Dmitry
On 2013-09-20 00:21, Seán Coffey wrote:
Looking for review
Looking for review on recently reported issue. Issue seen on windows
when a custom socketImpl is in use.
bug report : https://bugs.openjdk.java.net/browse/JDK-8024952
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/
Regards,
Sean.
On the regression testcase theme, it got me thinking as to whether we've
any java APIs which can query what the native heap usage of the JVM. Is
that available over JMX ?
I tried the MBeanServer approach but didn't get the expected results.
Queried the NonHeapMemoryUsage object.
something
8007315 deals with an issue in SAAJ code where a NullPointerException is
seen.
The SAAJ code makes the assumption that non-null keys obtained from a
httpURLConnection header will contain non-null values :
294 key = httpConnection.getHeaderFieldKey(i);
295
Requesting a review for this bug which cropped up whilst cleaning up the
FileDescriptor associated streams some time back (7105952)
Turns out that each call to a socket.getOutputStream() creates a new
instance of SocketOutputStream. I'm not seeing any reason to why that
code exists. One
Approved.
regards,
Sean.
On 28/08/2012 10:00, Chris Hegarty wrote:
Hi,
This is a request for approval to backport the fix for 7188755 from
JDK8 to 7u8.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188755
7188755: Crash due to missing synchronization on gconf_client in
New changes look fine Chris.
regards,
Sean.
On 11/10/2011 11:51, Chris Hegarty wrote:
There was a cut'n'paste error in the original change for CR 7098719.
super.create(stream) should be reinstated.
After the above, now the (closed) regression test amended for CR
7098719 fails. The reason is
58 matches
Mail list logo
