PING: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing

2016-07-19 Thread Langer, Christoph
Hi all,

can I please get a review for my change: 
http://cr.openjdk.java.net/~clanger/webrevs/8160174.3/ ?

I made some minor updates in place, mostly formatting, to the version from one 
week ago. The only real change I made is that I now set the scope id of IPv6 
addresses to the interface index also on BSD, where it was not done before. 
Here I have the question if this is really the desired behavior to always set 
the interface as scope of any IPv6 address?

Thanks in advance
Christoph


> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 13. Juli 2016 17:02
> To: 'Chris Hegarty' 
> Cc: net-dev@openjdk.java.net
> Subject: RE: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and
> improvements for network interface listing
> 
> Hi Chris,
> 
> ok, here is my new version which I think is quite a nice cleanup - though
> probably not "S" any more:
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.3/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> 
> I updated the bug report to list all the small things that I've fixed. I now 
> took the
> approach to depuzzle all "enum*Interfaces" functions for the platforms and
> now the coding should really be easier to read - though, of course, some parts
> got duplicated.
> 
> The notable differences in the output of NetworkInterface.getAll() are that a)
> no broadcast address is returned any more for loopback addresses on Linux and
> b) subnet prefixes for AIX IPv6 interfaces should work now. The rest should be
> optimizations under the cover.
> 
> Please review.
> 
> Thanks
> Christoph
> 
> > -Original Message-
> > From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> > Sent: Dienstag, 12. Juli 2016 16:10
> > To: Langer, Christoph 
> > Cc: net-dev@openjdk.java.net
> > Subject: Re: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and
> > improvements for network interface listing
> >
> > Christoph,
> >
> > > On 11 Jul 2016, at 14:36, Langer, Christoph 
> > wrote:
> > >
> > > Hi Chris (or anyone who is holding a stake in the NetworkInterface native
> > implementation),
> > >
> > > I’ve spent some time on cleaning up NetworkInterface.c and came up with a
> > bigger change:http://cr.openjdk.java.net/~clanger/webrevs/8160174.2/
> > >
> > > With this I attempted to consolidate the interface listing functionality 
> > > of the
> 2
> > main categories – one is ioctl (used on Linux IPv4, Solaris and AIX) and the
> > other is getifaddrs (used on MacOS). I introduced some defines to switch
> > between the implementations. I also consolidated the functionality for the
> ioctl
> > based network interface listings by using an #ifdef section to distinguish
> > between the Linux/AIX versus Solaris field and constant names.
> > >
> > > I’ve spent some time testing on the platforms and in principal it works. 
> > > But
> as
> > it is a matter of taste, I’d like to ask you if you support this type of 
> > change or
> > have any hints or recommendations before going forward to finalize this.
> >
> > I’m personally don’t like this approach much. I think it adds further
> > complexity and difficulty to this code, which already has its fair share
> > of both.
> >
> > > For Linux I’m also suggesting to use the getifaddrs approach – I tested 
> > > and
> > found it working everywhere and with this we could get rid of the
> > implementation to read /proc/net for IPv6.
> >
> > You should probably break this type of change out, so that it can be
> > evaluated independently, on its own merit. If it add nothing more than
> > clean up, may it makes sense for this to happen early in 10, where it
> > can have a longer time to bake.
> >
> > > Furthermore I’m generally setting Null for the IPv6 broadcast address –
> which
> > I think is common sense for IPv6.
> >
> > Same as above.  This “smaller” changes can sometimes get lost in
> > the noise of larger refactoring.
> >
> > -Chris.
> >
> >
> > > Thanks in advance and best regards
> > > Christoph
> > >
> > >
> > > From: Langer, Christoph
> > > Sent: Donnerstag, 23. Juni 2016 16:37
> > > To: 'net-dev@openjdk.java.net' 
> > > Subject: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and
> > improvements for network interface listing
> > >
> > > Hi,
> > >
> > > can I please get a review the following change:
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.1/
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> > >
> > > I made further fixes and cleanups for listing Unix type network 
> > > interfaces,
> > especially on AIX and Linux. I ran builds and verified also on Solaris and 
> > Mac.
> > >
> > > Thanks
> > > Christoph



Re: RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

2016-07-19 Thread Sergey Kuksenko

Who could sponsor this?

On 07/14/2016 07:53 AM, Chris Hegarty wrote:

On 11 Jul 2016, at 23:47, Sergey Kuksenko  wrote:

I am awfully sorry, previous fix was incorrect.
Please, review the right version: 
http://cr.openjdk.java.net/~skuksenko/jep110/8161091/webrev.01/

Looks good. Thanks Sergey.

-Chris.


On 07/08/2016 02:40 PM, Sergey Kuksenko wrote:

Hi,
Could you please review the following fix for JDK-8161091?

http://cr.openjdk.java.net/~skuksenko/jep110/8161091/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8161091

Existing Stream.FlowControl implementation doesn't decrease amount of permits 
if requested amount is less than permits. That means that client may send any 
amount of data if data frame size less than window size.

Thank you,
Sergey Kuksenko.




Re: JDK 9 RFR of JDK-8161565: Problem list httpclient/SplitResponse.java and URLPermission/URLTest.java

2016-07-19 Thread Amy Lu

Please review.

Thanks,
Amy

On 7/18/16 1:48 PM, Amy Lu wrote:
Below tests have been observed to fail intermittently with relatively 
high frequency:


java/net/httpclient/SplitResponse.java (JDK-8157533)
java/net/URLPermission/URLTest.java (JDK-8078568)

Please review this patch to put them to problem list until issues 
addressed.


bug: https://bugs.openjdk.java.net/browse/JDK-8161565
webrev: http://cr.openjdk.java.net/~amlu/8161565/webrev.00/

Thanks,
Amy


--- old/test/ProblemList.txt2016-07-18 13:42:14.0 +0800
+++ new/test/ProblemList.txt2016-07-18 13:42:14.0 +0800
@@ -171,6 +171,10 @@
  
  java/net/DatagramSocket/SendDatagramToBadAddress.java   7143960 macosx-all
  
+java/net/URLPermission/URLTest.java 8078568 generic-all

+
+java/net/httpclient/SplitResponse.java  8157533 
generic-all
+
  java/net/httpclient/http2/BasicTest.java8157408 
linux-all
  java/net/httpclient/http2/ErrorTest.java8158127 
solaris-all,windows-all
  java/net/httpclient/http2/TLSConnection.java8157482 
macosx-all