From Alan.Bateman at oracle.com  Thu Sep  1 08:59:43 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 1 Sep 2016 09:59:43 +0100
Subject: Review request JDK-8165180: Provide a shared secret to access
	non-public ServerSocket constructor
In-Reply-To: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
References: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
Message-ID: <a59c48ac-011a-baf2-4613-5f1034170b1a@oracle.com>

On 31/08/2016 21:48, Mandy Chung wrote:

> This patch introduces JavaNetSocketAccess to allow access to non-public ServerSocket constructor that is accessed by some other area as a clean up.
>
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165180/webrev.00/
>
>
This looks okay to me.

-Alan

From chris.hegarty at oracle.com  Thu Sep  1 09:14:44 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 1 Sep 2016 10:14:44 +0100
Subject: java.net.http orElse(null) in SSLDelegate and other nits
In-Reply-To: <20160827182512.00003b56.ecki@zusammenkunft.net>
References: <20160827182512.00003b56.ecki@zusammenkunft.net>
Message-ID: <1A49F8EA-A759-46D4-B3FC-B7FA5C28342F@oracle.com>

Thanks for reporting these issues Bernd,

> On 27 Aug 2016, at 17:25, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 
> Hello,
> 
> trying to understand the new jdk9 hierachy I noticed that this code:
> 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/ca7fb78b94b6/src/java.httpclient/share/classes/java/net/http/SSLDelegate.java#l59
> 
>      SSLParameters sslp = client.sslParameters().orElse(null);
>      if (sslp == null) {
>          sslp = context.getSupportedSSLParameters();
>      }

Ugh!

> seems to use a Optional anti-pattern. How about:
> 
>    SSLParameters sslp = client.sslParameters().orElseGet(context::getSupportedSSLParameters);

That is much cleaner.
  http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9e00f30e37ca

> (If there is a reason for not using lambda, it might need a comment?)
> 
> Also I wonder if this parameter conversion and string concatenation should be conditional?
> 
> Log.logSSL("Setting application protocols: " + Arrays.toString(alpn));

Yes.
  http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/095cb9252d94

Both of these changes are in the http-client-branch of the sandbox and will
make it into  jdk9/dev in the next integration.

Thanks again,
-Chris.

From vyom.tewari at oracle.com  Thu Sep  1 16:03:31 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 1 Sep 2016 21:33:31 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
Message-ID: <3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>

please find the updated 
webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). I 
incorporated the review comments.

Thanks,

Vyom


On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>
> Hi
>   perhaps there is an opportunity to do  some refactoring here (...  
> for me a "goto " carries a code smell! )
>
> along the lines
>
> if (timeout) {
>     nread =  NET_ReadWithTimeout(...);
> } else {
>      nread = NET_Read(...);
> }
>
>
> the NET_ReadWithTimeout (...) function will contain a restructuring of 
> your goto loop
> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>            if (nread <= 0) {
>                if (nread == 0) {
>                    JNU_ThrowByName(env, JNU_JAVANETPKG "SocketTimeoutException",
>                                "Read timed out");
>                } else if (nread == -1) {
>                    if (errno == EBADF) {
>                         JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed");
>                    } else if (errno == ENOMEM) {
>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout native heap allocation failed");
>                    } else {
>                        JNU_ThrowByNameWithMessageAndLastError
>                            (env, JNU_JAVANETPKG "SocketException", "select/poll failed");
>                    }
>                }
>                  // release buffer in main call flow
> //              if (bufP != BUF) {
> //                  free(bufP);
> //             }
>               nread = -1;
>               break;
>            } else {
> nread = NET_NonBlockingRead(fd, bufP, len);
> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>                gettimeofday(&t, NULL);
> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> _timeout -= newtime - prevtime;
> if(_timeout > 0){
> prevtime = newtime;
>                    }
> } else { break; } } } return nread;
>
> e&oe
>
> regards
> Mark
>
>
> On 29/08/2016 10:58, Vyom Tewari wrote:
>> gentle reminder, please review the below code change.
>>
>> Vyom
>>
>>
>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>> Hi All,
>>>
>>> Please review the code changes for below issue.
>>>
>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>
>>> webrev    : 
>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html 
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>
>>> This issue is SocketInputStream.socketread0() hangs even with 
>>> "soTimeout" set.the implementation of 
>>> Java_java_net_SocketInputStream_socketRead0 assumes that read() 
>>> won't block after poll() reports that a read is possible.
>>>
>>> This assumption does not hold, as noted on the man page for select 
>>> (referenced by the man page for poll): Under Linux, select() may 
>>> report a socket file descriptor as "ready for reading", while 
>>> nevertheless a subsequent read blocks. This could for example happen 
>>> when data has arrived but upon examination has wrong checksum and is 
>>> discarded.
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160901/3ba71264/attachment.html>

From mark.sheppard at oracle.com  Thu Sep  1 17:51:25 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Thu, 1 Sep 2016 18:51:25 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
Message-ID: <50aa6f49-0c86-c77e-7d8a-2c1f188bce29@oracle.com>

Hi Vyom,
      thanks for doing the refactoring.
changes look OK to me

regards
Mark

On 01/09/2016 17:03, Vyom Tewari wrote:
>
> please find the updated 
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
> I incorporated the review comments.
>
> Thanks,
>
> Vyom
>
>
> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>
>> Hi
>>   perhaps there is an opportunity to do  some refactoring here (...  
>> for me a "goto " carries a code smell! )
>>
>> along the lines
>>
>> if (timeout) {
>>     nread =  NET_ReadWithTimeout(...);
>> } else {
>>      nread = NET_Read(...);
>> }
>>
>>
>> the NET_ReadWithTimeout (...) function will contain a restructuring 
>> of your goto loop
>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>            if (nread <= 0) {
>>                if (nread == 0) {
>>                    JNU_ThrowByName(env, JNU_JAVANETPKG "SocketTimeoutException",
>>                                "Read timed out");
>>                } else if (nread == -1) {
>>                    if (errno == EBADF) {
>>                         JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed");
>>                    } else if (errno == ENOMEM) {
>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout native heap allocation failed");
>>                    } else {
>>                        JNU_ThrowByNameWithMessageAndLastError
>>                            (env, JNU_JAVANETPKG "SocketException", "select/poll failed");
>>                    }
>>                }
>>                  // release buffer in main call flow
>> //              if (bufP != BUF) {
>> //                  free(bufP);
>> //             }
>>               nread = -1;
>>               break;
>>            } else {
>> nread = NET_NonBlockingRead(fd, bufP, len);
>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>                gettimeofday(&t, NULL);
>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>> _timeout -= newtime - prevtime;
>> if(_timeout > 0){
>> prevtime = newtime;
>>                    }
>> } else { break; } } } return nread;
>>
>> e&oe
>>
>> regards
>> Mark
>>
>>
>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>> gentle reminder, please review the below code change.
>>>
>>> Vyom
>>>
>>>
>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>> Hi All,
>>>>
>>>> Please review the code changes for below issue.
>>>>
>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>
>>>> webrev    : 
>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html 
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>
>>>> This issue is SocketInputStream.socketread0() hangs even with 
>>>> "soTimeout" set.the implementation of 
>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read() 
>>>> won't block after poll() reports that a read is possible.
>>>>
>>>> This assumption does not hold, as noted on the man page for select 
>>>> (referenced by the man page for poll): Under Linux, select() may 
>>>> report a socket file descriptor as "ready for reading", while 
>>>> nevertheless a subsequent read blocks. This could for example 
>>>> happen when data has arrived but upon examination has wrong 
>>>> checksum and is discarded.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160901/46eb4ad2/attachment-0001.html>

From christoph.langer at sap.com  Thu Sep  1 18:57:51 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 1 Sep 2016 18:57:51 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <50aa6f49-0c86-c77e-7d8a-2c1f188bce29@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<50aa6f49-0c86-c77e-7d8a-2c1f188bce29@oracle.com>
Message-ID: <4b177d39fbb744a3bc01dbd8a688decc@DEWDFE13DE11.global.corp.sap>

+1

From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Mark Sheppard
Sent: Donnerstag, 1. September 2016 19:51
To: Vyom Tewari <vyom.tewari at oracle.com>; net-dev at openjdk.java.net
Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Hi Vyom,
     thanks for doing the refactoring.
changes look OK to me

regards
Mark
On 01/09/2016 17:03, Vyom Tewari wrote:

please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). I incorporated the review comments.

Thanks,

Vyom

On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:

Hi
  perhaps there is an opportunity to do  some refactoring here (...  for me a "goto " carries a code smell! )

along the lines

if (timeout) {
    nread =  NET_ReadWithTimeout(...);
} else {
     nread = NET_Read(...);
}


the NET_ReadWithTimeout (...) function will contain a restructuring of your goto loop

        while (_timeout > 0) {

          nread = NET_Timeout(fd, _timeout);

          if (nread <= 0) {

              if (nread == 0) {

                  JNU_ThrowByName(env, JNU_JAVANETPKG "SocketTimeoutException",

                              "Read timed out");

              } else if (nread == -1) {

                  if (errno == EBADF) {

                       JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed");

                  } else if (errno == ENOMEM) {

                      JNU_ThrowOutOfMemoryError(env, "NET_Timeout native heap allocation failed");

                  } else {

                      JNU_ThrowByNameWithMessageAndLastError

                          (env, JNU_JAVANETPKG "SocketException", "select/poll failed");

                  }

              }

                // release buffer in main call flow

//              if (bufP != BUF) {

//                  free(bufP);

//             }

             nread = -1;

             break;

          } else {

              nread = NET_NonBlockingRead(fd, bufP, len);

              if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {

                  gettimeofday(&t, NULL);

                  newtime = t.tv_sec * 1000 + t.tv_usec / 1000;

                  _timeout -= newtime - prevtime;

                  if(_timeout > 0){

                      prevtime = newtime;

                  }

              } else {

                  break;

              }

          }

       }



        return nread;



e&oe

regards
Mark

On 29/08/2016 10:58, Vyom Tewari wrote:
gentle reminder, please review the below code change.

Vyom


On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:

Hi All,

Please review the code changes for below issue.

Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484

webrev    : http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html><http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>

This issue is SocketInputStream.socketread0() hangs even with "soTimeout" set.the implementation of Java_java_net_SocketInputStream_socketRead0 assumes that read() won't block after poll() reports that a read is possible.

This assumption does not hold, as noted on the man page for select (referenced by the man page for poll): Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded.

Thanks,

Vyom





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160901/b13dce90/attachment.html>

From dmitry.samersoff at oracle.com  Thu Sep  1 20:08:15 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 1 Sep 2016 23:08:15 +0300
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
Message-ID: <2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>

Vyom,

Did you consider to use select() to calculate timeout instead of
gettimeofday ?

gettimeofday is affected by system time changes, so running ntpd can
cause unpredictable behavior of this code. Also it's rather expensive
syscall.

-Dmitry

On 2016-09-01 19:03, Vyom Tewari wrote:
> please find the updated
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). I
> incorporated the review comments.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>
>> Hi
>>   perhaps there is an opportunity to do  some refactoring here (... 
>> for me a "goto " carries a code smell! )
>>
>> along the lines
>>
>> if (timeout) {
>>     nread =  NET_ReadWithTimeout(...);
>> } else {
>>      nread = NET_Read(...);
>> }
>>
>>
>> the NET_ReadWithTimeout (...) function will contain a restructuring of
>> your goto loop
>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>           if (nread <= 0) {
>>               if (nread == 0) {
>>                   JNU_ThrowByName(env, JNU_JAVANETPKG "SocketTimeoutException",
>>                               "Read timed out");
>>               } else if (nread == -1) {
>>                   if (errno == EBADF) {
>>                        JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed");
>>                   } else if (errno == ENOMEM) {
>>                       JNU_ThrowOutOfMemoryError(env, "NET_Timeout native heap allocation failed");
>>                   } else {
>>                       JNU_ThrowByNameWithMessageAndLastError
>>                           (env, JNU_JAVANETPKG "SocketException", "select/poll failed");
>>                   }
>>               }
>>                 // release buffer in main call flow
>> //              if (bufP != BUF) {
>> //                  free(bufP);
>> //             }
>>              nread = -1;
>>              break;
>>           } else {
>> nread = NET_NonBlockingRead(fd, bufP, len);
>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>               gettimeofday(&t, NULL);
>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>> _timeout -= newtime - prevtime;
>> if(_timeout > 0){
>> prevtime = newtime;
>>                   }
>> } else { break; } } } return nread;
>>
>> e&oe
>>
>> regards
>> Mark
>>
>>
>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>> gentle reminder, please review the below code change.
>>>
>>> Vyom
>>>
>>>
>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>> Hi All,
>>>>
>>>> Please review the code changes for below issue.
>>>>
>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>
>>>> webrev    :
>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>
>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>> "soTimeout" set.the implementation of
>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>> won't block after poll() reports that a read is possible.
>>>>
>>>> This assumption does not hold, as noted on the man page for select
>>>> (referenced by the man page for poll): Under Linux, select() may
>>>> report a socket file descriptor as "ready for reading", while
>>>> nevertheless a subsequent read blocks. This could for example happen
>>>> when data has arrived but upon examination has wrong checksum and is
>>>> discarded.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From ecki at zusammenkunft.net  Thu Sep  1 20:28:38 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 1 Sep 2016 22:28:38 +0200
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
Message-ID: <20160901222838.000067c0.ecki@zusammenkunft.net>

Am Thu, 1 Sep 2016 23:08:15 +0300
schrieb Dmitry Samersoff <dmitry.samersoff at oracle.com>:

> gettimeofday is affected by system time changes, so running ntpd can
> cause unpredictable behavior of this code. Also it's rather expensive
> syscall.

At least on Linux It is actually not a syscall at all and very
performant (on Linux gettimeofday and clock_gettime are VDSOs).

But I would agree, for timeouts a clock_gettime(CLOCK_MONOTONIC_COARSE
or RAW) should be used.

However, this really should be a general JVM abstraction...

Gruss
Bernd

> 
> -Dmitry
> 
> On 2016-09-01 19:03, Vyom Tewari wrote:
> > please find the updated
> > webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> > <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
> > I incorporated the review comments.
> > 
> > Thanks,
> > 
> > Vyom
> > 
> > 
> > On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
> >>
> >> Hi
> >>   perhaps there is an opportunity to do  some refactoring here
> >> (... for me a "goto " carries a code smell! )
> >>
> >> along the lines
> >>
> >> if (timeout) {
> >>     nread =  NET_ReadWithTimeout(...);
> >> } else {
> >>      nread = NET_Read(...);
> >> }
> >>
> >>
> >> the NET_ReadWithTimeout (...) function will contain a
> >> restructuring of your goto loop
> >> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
> >>           if (nread <= 0) {
> >>               if (nread == 0) {
> >>                   JNU_ThrowByName(env, JNU_JAVANETPKG
> >> "SocketTimeoutException", "Read timed out");
> >>               } else if (nread == -1) {
> >>                   if (errno == EBADF) {
> >>                        JNU_ThrowByName(env, JNU_JAVANETPKG
> >> "SocketException", "Socket closed"); } else if (errno == ENOMEM) {
> >>                       JNU_ThrowOutOfMemoryError(env, "NET_Timeout
> >> native heap allocation failed"); } else {
> >>                       JNU_ThrowByNameWithMessageAndLastError
> >>                           (env, JNU_JAVANETPKG "SocketException",
> >> "select/poll failed"); }
> >>               }
> >>                 // release buffer in main call flow
> >> //              if (bufP != BUF) {
> >> //                  free(bufP);
> >> //             }
> >>              nread = -1;
> >>              break;
> >>           } else {
> >> nread = NET_NonBlockingRead(fd, bufP, len);
> >> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
> >>               gettimeofday(&t, NULL);
> >> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> >> _timeout -= newtime - prevtime;
> >> if(_timeout > 0){
> >> prevtime = newtime;
> >>                   }
> >> } else { break; } } } return nread;
> >>
> >> e&oe
> >>
> >> regards
> >> Mark
> >>
> >>
> >> On 29/08/2016 10:58, Vyom Tewari wrote:
> >>> gentle reminder, please review the below code change.
> >>>
> >>> Vyom
> >>>
> >>>
> >>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
> >>>> Hi All,
> >>>>
> >>>> Please review the code changes for below issue.
> >>>>
> >>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
> >>>>
> >>>> webrev    :
> >>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> >>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >>>>
> >>>> This issue is SocketInputStream.socketread0() hangs even with
> >>>> "soTimeout" set.the implementation of
> >>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
> >>>> won't block after poll() reports that a read is possible.
> >>>>
> >>>> This assumption does not hold, as noted on the man page for
> >>>> select (referenced by the man page for poll): Under Linux,
> >>>> select() may report a socket file descriptor as "ready for
> >>>> reading", while nevertheless a subsequent read blocks. This
> >>>> could for example happen when data has arrived but upon
> >>>> examination has wrong checksum and is discarded.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Vyom
> >>>>
> >>>>
> >>>
> >>
> > 
> 
> 


From vyom.tewari at oracle.com  Fri Sep  2 03:39:15 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Fri, 2 Sep 2016 09:09:15 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
Message-ID: <26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>

hi Dimitry,

thanks for review, I did consider to use  a monotonically increasing 
clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses 
"gettimeofday"  so i choose to be consistent with the existing code.

Thanks,

Vyom


On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
> Vyom,
>
> Did you consider to use select() to calculate timeout instead of
> gettimeofday ?
>
> gettimeofday is affected by system time changes, so running ntpd can
> cause unpredictable behavior of this code. Also it's rather expensive
> syscall.
>
> -Dmitry
>
> On 2016-09-01 19:03, Vyom Tewari wrote:
>> please find the updated
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). I
>> incorporated the review comments.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>> Hi
>>>    perhaps there is an opportunity to do  some refactoring here (...
>>> for me a "goto " carries a code smell! )
>>>
>>> along the lines
>>>
>>> if (timeout) {
>>>      nread =  NET_ReadWithTimeout(...);
>>> } else {
>>>       nread = NET_Read(...);
>>> }
>>>
>>>
>>> the NET_ReadWithTimeout (...) function will contain a restructuring of
>>> your goto loop
>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>            if (nread <= 0) {
>>>                if (nread == 0) {
>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG "SocketTimeoutException",
>>>                                "Read timed out");
>>>                } else if (nread == -1) {
>>>                    if (errno == EBADF) {
>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed");
>>>                    } else if (errno == ENOMEM) {
>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout native heap allocation failed");
>>>                    } else {
>>>                        JNU_ThrowByNameWithMessageAndLastError
>>>                            (env, JNU_JAVANETPKG "SocketException", "select/poll failed");
>>>                    }
>>>                }
>>>                  // release buffer in main call flow
>>> //              if (bufP != BUF) {
>>> //                  free(bufP);
>>> //             }
>>>               nread = -1;
>>>               break;
>>>            } else {
>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>                gettimeofday(&t, NULL);
>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>> _timeout -= newtime - prevtime;
>>> if(_timeout > 0){
>>> prevtime = newtime;
>>>                    }
>>> } else { break; } } } return nread;
>>>
>>> e&oe
>>>
>>> regards
>>> Mark
>>>
>>>
>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>> gentle reminder, please review the below code change.
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the code changes for below issue.
>>>>>
>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>
>>>>> webrev    :
>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>
>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>> "soTimeout" set.the implementation of
>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>> won't block after poll() reports that a read is possible.
>>>>>
>>>>> This assumption does not hold, as noted on the man page for select
>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>> report a socket file descriptor as "ready for reading", while
>>>>> nevertheless a subsequent read blocks. This could for example happen
>>>>> when data has arrived but upon examination has wrong checksum and is
>>>>> discarded.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>


From christoph.langer at sap.com  Fri Sep  2 07:22:26 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 2 Sep 2016 07:22:26 +0000
Subject: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface
	native implementation
Message-ID: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>

Hi (Mark or Chris?),

as this RFR is outstanding for quite a while and it merely is a minor change which only cleans up coding, would you mind to review it that I can get it off my list?

The only major thing probably is, that calls to getMacAddress don't need a socket anymore and sockets are only opened for platforms where an ioctl is done to determine the MacAddress.

As I've said, I've tested it on the Linux/Unix platforms.

Thanks a lot
Christoph

From: Langer, Christoph
Sent: Montag, 22. August 2016 15:30
To: 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net>
Subject: RE: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Hi,

I made a little update to my change: http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/

Merely comments and a minor AIX specific correction.

Thanks in advance for reviewing
Christoph


From: Langer, Christoph
Sent: Dienstag, 16. August 2016 14:49
To: 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>>
Subject: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Ping: Can I get a review for this small set of changes please?

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 4. August 2016 15:04
To: net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>
Subject: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Hi,

I had made a few more cleanups when I was working on NetworkInterface.c which I thought are worth contributing.

Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/
Bug: https://bugs.openjdk.java.net/browse/JDK-8163181

As always, changes were built and tested on Linux, AIX, Solaris and Mac.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160902/7bc1b837/attachment.html>

From chris.hegarty at oracle.com  Fri Sep  2 08:10:33 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 2 Sep 2016 09:10:33 +0100
Subject: Ping: RFR(S): 8163181: Further improvements for Unix
	NetworkInterface native implementation
In-Reply-To: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
References: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
Message-ID: <B8137A74-F32B-4785-8858-6520E5B2E364@oracle.com>

Apologies Christoph, this dropped off my list and I forgot to get back to it.

> On 2 Sep 2016, at 08:22, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi (Mark or Chris?),
>  
> as this RFR is outstanding for quite a while and it merely is a minor change which only cleans up coding, would you mind to review it that I can get it off my list?
>  
> The only major thing probably is, that calls to getMacAddress don?t need a socket anymore and sockets are only opened for platforms where an ioctl is done to determine the MacAddress.
>  
> As I?ve said, I?ve tested it on the Linux/Unix platforms.
>  
> Thanks a lot
> Christoph
>  
> From: Langer, Christoph 
> Sent: Montag, 22. August 2016 15:30
> To: 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net>
> Subject: RE: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation
>  
> Hi,
>  
> I made a little update to my change: http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/


Your changes look fine to me. This is a natural cleanup now that we have
moved away from ioctl on some platforms.

I will submit your patch to our internal build and test system, and report
back the results later today.

-Chris.


> Merely comments and a minor AIX specific correction.
>  
> Thanks in advance for reviewing
> Christoph
>  
>  
> From: Langer, Christoph 
> Sent: Dienstag, 16. August 2016 14:49
> To: 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net>
> Subject: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation
>  
> Ping: Can I get a review for this small set of changes please?
>  
> Thanks
> Christoph
>  
> From: Langer, Christoph 
> Sent: Donnerstag, 4. August 2016 15:04
> To: net-dev at openjdk.java.net
> Subject: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation
>  
> Hi,
>  
> I had made a few more cleanups when I was working on NetworkInterface.c which I thought are worth contributing.
>  
> Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163181
>  
> As always, changes were built and tested on Linux, AIX, Solaris and Mac.
>  
> Thanks
> Christoph


From dmitry.samersoff at oracle.com  Fri Sep  2 10:20:18 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 2 Sep 2016 13:20:18 +0300
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
Message-ID: <b3b531f6-c844-122c-2087-4b8987aed4c5@oracle.com>

Vyom,

> thanks for review, I did consider to use  a monotonically increasing
> clock like "clock_gettime" but  existing nearby code("NET_Timeout")
> uses "gettimeofday"  so i choose to be consistent with the existing
> code.

OK. The fix looks good for me.

-Dmitry


On 2016-09-02 06:39, Vyom Tewari wrote:
> hi Dimitry,
> 
> thanks for review, I did consider to use  a monotonically increasing
> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
> "gettimeofday"  so i choose to be consistent with the existing code.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>> Vyom,
>>
>> Did you consider to use select() to calculate timeout instead of
>> gettimeofday ?
>>
>> gettimeofday is affected by system time changes, so running ntpd can
>> cause unpredictable behavior of this code. Also it's rather expensive
>> syscall.
>>
>> -Dmitry
>>
>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>> please find the updated
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). I
>>> incorporated the review comments.
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>> Hi
>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>> for me a "goto " carries a code smell! )
>>>>
>>>> along the lines
>>>>
>>>> if (timeout) {
>>>>      nread =  NET_ReadWithTimeout(...);
>>>> } else {
>>>>       nread = NET_Read(...);
>>>> }
>>>>
>>>>
>>>> the NET_ReadWithTimeout (...) function will contain a restructuring of
>>>> your goto loop
>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>            if (nread <= 0) {
>>>>                if (nread == 0) {
>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>> "SocketTimeoutException",
>>>>                                "Read timed out");
>>>>                } else if (nread == -1) {
>>>>                    if (errno == EBADF) {
>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>> "SocketException", "Socket closed");
>>>>                    } else if (errno == ENOMEM) {
>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>> native heap allocation failed");
>>>>                    } else {
>>>>                        JNU_ThrowByNameWithMessageAndLastError
>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>> "select/poll failed");
>>>>                    }
>>>>                }
>>>>                  // release buffer in main call flow
>>>> //              if (bufP != BUF) {
>>>> //                  free(bufP);
>>>> //             }
>>>>               nread = -1;
>>>>               break;
>>>>            } else {
>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>                gettimeofday(&t, NULL);
>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>> _timeout -= newtime - prevtime;
>>>> if(_timeout > 0){
>>>> prevtime = newtime;
>>>>                    }
>>>> } else { break; } } } return nread;
>>>>
>>>> e&oe
>>>>
>>>> regards
>>>> Mark
>>>>
>>>>
>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>> gentle reminder, please review the below code change.
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the code changes for below issue.
>>>>>>
>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>
>>>>>> webrev    :
>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>
>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>> "soTimeout" set.the implementation of
>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>> won't block after poll() reports that a read is possible.
>>>>>>
>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>> nevertheless a subsequent read blocks. This could for example happen
>>>>>> when data has arrived but upon examination has wrong checksum and is
>>>>>> discarded.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From mark.sheppard at oracle.com  Fri Sep  2 11:41:32 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 2 Sep 2016 12:41:32 +0100
Subject: Ping: RFR(S): 8163181: Further improvements for Unix
	NetworkInterface native implementation
In-Reply-To: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
References: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
Message-ID: <c4c73e06-28c9-ee4c-3f04-436942debd3b@oracle.com>


have had a look through the changes twice, and they look fine ... i'll 
apply the patch and run a regression build to confirm

the moving of int flags on 919 to a conditional block,  I expect to 
cause a strict compile error in my solaris env, so need to check that

regards
Mark

On 02/09/2016 08:22, Langer, Christoph wrote:
>
> Hi (Mark or Chris?),
>
> as this RFR is outstanding for quite a while and it merely is a minor 
> change which only cleans up coding, would you mind to review it that I 
> can get it off my list?
>
> The only major thing probably is, that calls to getMacAddress don?t 
> need a socket anymore and sockets are only opened for platforms where 
> an ioctl is done to determine the MacAddress.
>
> As I?ve said, I?ve tested it on the Linux/Unix platforms.
>
> Thanks a lot
>
> Christoph
>
> *From:*Langer, Christoph
> *Sent:* Montag, 22. August 2016 15:30
> *To:* 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net>
> *Subject:* RE: Ping: RFR(S): 8163181: Further improvements for Unix 
> NetworkInterface native implementation
>
> Hi,
>
> I made a little update to my change: 
> http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.2/>
>
> Merely comments and a minor AIX specific correction.
>
> Thanks in advance for reviewing
>
> Christoph
>
> *From:*Langer, Christoph
> *Sent:* Dienstag, 16. August 2016 14:49
> *To:* 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net 
> <mailto:net-dev at openjdk.java.net>>
> *Subject:* Ping: RFR(S): 8163181: Further improvements for Unix 
> NetworkInterface native implementation
>
> Ping: Can I get a review for this small set of changes please?
>
> Thanks
>
> Christoph
>
> *From:*Langer, Christoph
> *Sent:* Donnerstag, 4. August 2016 15:04
> *To:* net-dev at openjdk.java.net <mailto:net-dev at openjdk.java.net>
> *Subject:* RFR(S): 8163181: Further improvements for Unix 
> NetworkInterface native implementation
>
> Hi,
>
> I had made a few more cleanups when I was working on 
> NetworkInterface.c which I thought are worth contributing.
>
> Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.1/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163181 
> <https://bugs.openjdk.java.net/browse/JDK-8163181>
>
> As always, changes were built and tested on Linux, AIX, Solaris and Mac.
>
> Thanks
>
> Christoph
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160902/f62c0fc2/attachment.html>

From peter.levart at gmail.com  Fri Sep  2 13:42:45 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 2 Sep 2016 15:42:45 +0200
Subject: Review request JDK-8165180: Provide a shared secret to access
	non-public ServerSocket constructor
In-Reply-To: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
References: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
Message-ID: <14eb81ac-efdb-4f58-ff2d-3fcdd798d7fb@gmail.com>

Hi Many,

Are you sure the implementation class passed to 
JavaNetSocketAccess.newSocketImpl(Class<? extends SocketImpl> implClass) 
is never going to be loaded by a class loader other than bootstrap 
classloader (the loader of the caller of 
implClass.getDeclaredConstructor()) and that no unprivileged code will 
be on the call stack at that time? Do you need to enclose this 
invocation into doPrivileged() block or do you expect that the caller of 
JavaNetSocketAccess.newSocketImpl() will do that?

Regards, Peter

On 08/31/2016 10:48 PM, Mandy Chung wrote:
> This patch introduces JavaNetSocketAccess to allow access to non-public ServerSocket constructor that is accessed by some other area as a clean up.
>
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165180/webrev.00/
>
> Mandy


From christoph.langer at sap.com  Fri Sep  2 14:02:56 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 2 Sep 2016 14:02:56 +0000
Subject: [8u-dev] RFR (XXS) and request for approval: 8165320: Small flaw when
	integrating 8160174 to JDK8
Message-ID: <7734b71fa5cf437bada1cd2a4bc55141@DEWDFE13DE11.global.corp.sap>

Hi,

can you please review and approve a tiny and straightforward fix for AIX only in JDK8.

Bug: https://bugs.openjdk.java.net/browse/JDK-8165320
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165320.8udev/

When integrating 8160174, I oversaw 2 minor places where JVM_Socket should be used instead of calling the socket API directly for the AIX branch. All other operating systems are not affected and the code is correct there.

@Chris: Maybe you can review this straightforward?

Thanks & Best regards
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160902/4ab900c3/attachment-0001.html>

From mark.sheppard at oracle.com  Fri Sep  2 14:49:41 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 2 Sep 2016 15:49:41 +0100
Subject: Ping: RFR(S): 8163181: Further improvements for Unix
	NetworkInterface native implementation
In-Reply-To: <c4c73e06-28c9-ee4c-3f04-436942debd3b@oracle.com>
References: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
	<c4c73e06-28c9-ee4c-3f04-436942debd3b@oracle.com>
Message-ID: <d3a9aaf5-f1fd-b23a-d45d-27e67698d538@oracle.com>


builds and regression tests appear to be OK with the proposed changes.

regards
Mark

On 02/09/2016 12:41, Mark Sheppard wrote:
>
> have had a look through the changes twice, and they look fine ... i'll 
> apply the patch and run a regression build to confirm
>
> the moving of int flags on 919 to a conditional block,  I expect to 
> cause a strict compile error in my solaris env, so need to check that
>
> regards
> Mark
>
> On 02/09/2016 08:22, Langer, Christoph wrote:
>>
>> Hi (Mark or Chris?),
>>
>> as this RFR is outstanding for quite a while and it merely is a minor 
>> change which only cleans up coding, would you mind to review it that 
>> I can get it off my list?
>>
>> The only major thing probably is, that calls to getMacAddress don?t 
>> need a socket anymore and sockets are only opened for platforms where 
>> an ioctl is done to determine the MacAddress.
>>
>> As I?ve said, I?ve tested it on the Linux/Unix platforms.
>>
>> Thanks a lot
>>
>> Christoph
>>
>> *From:*Langer, Christoph
>> *Sent:* Montag, 22. August 2016 15:30
>> *To:* 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net>
>> *Subject:* RE: Ping: RFR(S): 8163181: Further improvements for Unix 
>> NetworkInterface native implementation
>>
>> Hi,
>>
>> I made a little update to my change: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/ 
>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.2/>
>>
>> Merely comments and a minor AIX specific correction.
>>
>> Thanks in advance for reviewing
>>
>> Christoph
>>
>> *From:*Langer, Christoph
>> *Sent:* Dienstag, 16. August 2016 14:49
>> *To:* 'net-dev at openjdk.java.net' <net-dev at openjdk.java.net 
>> <mailto:net-dev at openjdk.java.net>>
>> *Subject:* Ping: RFR(S): 8163181: Further improvements for Unix 
>> NetworkInterface native implementation
>>
>> Ping: Can I get a review for this small set of changes please?
>>
>> Thanks
>>
>> Christoph
>>
>> *From:*Langer, Christoph
>> *Sent:* Donnerstag, 4. August 2016 15:04
>> *To:* net-dev at openjdk.java.net <mailto:net-dev at openjdk.java.net>
>> *Subject:* RFR(S): 8163181: Further improvements for Unix 
>> NetworkInterface native implementation
>>
>> Hi,
>>
>> I had made a few more cleanups when I was working on 
>> NetworkInterface.c which I thought are worth contributing.
>>
>> Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/ 
>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.1/>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163181 
>> <https://bugs.openjdk.java.net/browse/JDK-8163181>
>>
>> As always, changes were built and tested on Linux, AIX, Solaris and Mac.
>>
>> Thanks
>>
>> Christoph
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160902/a08a9130/attachment.html>

From christoph.langer at sap.com  Fri Sep  2 14:51:13 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 2 Sep 2016 14:51:13 +0000
Subject: Ping: RFR(S): 8163181: Further improvements for Unix
	NetworkInterface native implementation
In-Reply-To: <d3a9aaf5-f1fd-b23a-d45d-27e67698d538@oracle.com>
References: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
	<c4c73e06-28c9-ee4c-3f04-436942debd3b@oracle.com>
	<d3a9aaf5-f1fd-b23a-d45d-27e67698d538@oracle.com>
Message-ID: <dba5047ced464031a8b16ae8d64376e5@DEWDFE13DE11.global.corp.sap>

That's great, thanks.

I'll push on Monday.

Best regards
Christoph

From: Mark Sheppard [mailto:mark.sheppard at oracle.com]
Sent: Freitag, 2. September 2016 16:50
To: Langer, Christoph <christoph.langer at sap.com>; net-dev at openjdk.java.net
Subject: Re: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation


builds and regression tests appear to be OK with the proposed changes.

regards
Mark
On 02/09/2016 12:41, Mark Sheppard wrote:

have had a look through the changes twice, and they look fine ... i'll apply the patch and run a regression build to confirm

the moving of int flags on 919 to a conditional block,  I expect to cause a strict compile error in my solaris env, so need to check that

regards
Mark
On 02/09/2016 08:22, Langer, Christoph wrote:
Hi (Mark or Chris?),

as this RFR is outstanding for quite a while and it merely is a minor change which only cleans up coding, would you mind to review it that I can get it off my list?

The only major thing probably is, that calls to getMacAddress don't need a socket anymore and sockets are only opened for platforms where an ioctl is done to determine the MacAddress.

As I've said, I've tested it on the Linux/Unix platforms.

Thanks a lot
Christoph

From: Langer, Christoph
Sent: Montag, 22. August 2016 15:30
To: 'net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>' <net-dev at openjdk.java.net><mailto:net-dev at openjdk.java.net>
Subject: RE: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Hi,

I made a little update to my change: http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.2/>

Merely comments and a minor AIX specific correction.

Thanks in advance for reviewing
Christoph


From: Langer, Christoph
Sent: Dienstag, 16. August 2016 14:49
To: 'net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>' <net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>>
Subject: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Ping: Can I get a review for this small set of changes please?

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 4. August 2016 15:04
To: net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>
Subject: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Hi,

I had made a few more cleanups when I was working on NetworkInterface.c which I thought are worth contributing.

Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.1/>
Bug: https://bugs.openjdk.java.net/browse/JDK-8163181

As always, changes were built and tested on Linux, AIX, Solaris and Mac.

Thanks
Christoph



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160902/2db02a6e/attachment-0001.html>

From chris.hegarty at oracle.com  Fri Sep  2 15:00:07 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 2 Sep 2016 16:00:07 +0100
Subject: [8u-dev] RFR (XXS) and request for approval: 8165320: Small flaw
	when integrating 8160174 to JDK8
In-Reply-To: <7734b71fa5cf437bada1cd2a4bc55141@DEWDFE13DE11.global.corp.sap>
References: <7734b71fa5cf437bada1cd2a4bc55141@DEWDFE13DE11.global.corp.sap>
Message-ID: <087925a1-adc8-bdac-bb22-6cf232bd5463@oracle.com>

On 02/09/16 15:02, Langer, Christoph wrote:
> Hi,
>
>
>
> can you please review and approve a tiny and straightforward fix for AIX
> only in JDK8.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165320
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165320.8udev/

This looks fine. Reviewed.

-Chris.

>
> When integrating 8160174, I oversaw 2 minor places where JVM_Socket
> should be used instead of calling the socket API directly for the AIX
> branch. All other operating systems are not affected and the code is
> correct there.
>
>
>
> @Chris: Maybe you can review this straightforward?
>
>
>
> Thanks & Best regards
>
> Christoph
>
>
>

From mandy.chung at oracle.com  Fri Sep  2 15:30:24 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 2 Sep 2016 08:30:24 -0700
Subject: Review request JDK-8165180: Provide a shared secret to access
	non-public ServerSocket constructor
In-Reply-To: <14eb81ac-efdb-4f58-ff2d-3fcdd798d7fb@gmail.com>
References: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
	<14eb81ac-efdb-4f58-ff2d-3fcdd798d7fb@gmail.com>
Message-ID: <18A33B58-0625-4D30-B4E6-246CD6E00903@oracle.com>

Constructor::newInstance is a caller-sensitive method that performs the security check when the caller is not the same class loader as implClass?s class loader or not its ancestor.

In this case the caller class is ServerSocket and its class loader is the bootstrap class loader is privileged (an ancestor of any loader).

Mandy

> On Sep 2, 2016, at 6:42 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Many,
> 
> Are you sure the implementation class passed to JavaNetSocketAccess.newSocketImpl(Class<? extends SocketImpl> implClass) is never going to be loaded by a class loader other than bootstrap classloader (the loader of the caller of implClass.getDeclaredConstructor()) and that no unprivileged code will be on the call stack at that time? Do you need to enclose this invocation into doPrivileged() block or do you expect that the caller of JavaNetSocketAccess.newSocketImpl() will do that?
> 
> Regards, Peter
> 
> On 08/31/2016 10:48 PM, Mandy Chung wrote:
>> This patch introduces JavaNetSocketAccess to allow access to non-public ServerSocket constructor that is accessed by some other area as a clean up.
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165180/webrev.00/
>> 
>> Mandy
> 


From chris.hegarty at oracle.com  Sat Sep  3 18:47:50 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 3 Sep 2016 19:47:50 +0100
Subject: HTTP client API
In-Reply-To: <CA+kOe0-2=r8pZW=+S-FDR0TCPoQA8OD5NyHM0-c+YWZ1LLk64w@mail.gmail.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<CA+kOe0-2=r8pZW=+S-FDR0TCPoQA8OD5NyHM0-c+YWZ1LLk64w@mail.gmail.com>
Message-ID: <37C16C63-0879-4062-A527-0248EFCD7279@oracle.com>

Martin, Wenbo,

We are considering the feedback, will take it under advisement, and
reply in due course.

-Chris.

> On 26 Aug 2016, at 22:14, Martin Buchholz <martinrb at google.com> wrote:
> 
> I don't know much about http, but I believe those who say that it's very hard to get the API right.  Perhaps it would be best to deliver a http client library as an independent beta package for use with jdk 8+ with a final version becoming part of jdk 10?  Perhaps there can be a productive collaboration here with companies for which http is bread-n-butter?
> 
> As a precedent, jsr166 historically released independent jars in this way in the jsr166* packages
> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html <http://gee.cs.oswego.edu/dl/concurrency-interest/index.html>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160903/679a9423/attachment.html>

From peter.levart at gmail.com  Mon Sep  5 07:19:27 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 5 Sep 2016 09:19:27 +0200
Subject: Review request JDK-8165180: Provide a shared secret to access
	non-public ServerSocket constructor
In-Reply-To: <18A33B58-0625-4D30-B4E6-246CD6E00903@oracle.com>
References: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
	<14eb81ac-efdb-4f58-ff2d-3fcdd798d7fb@gmail.com>
	<18A33B58-0625-4D30-B4E6-246CD6E00903@oracle.com>
Message-ID: <f211de88-02e8-c4da-e7c2-47bf2411631a@gmail.com>

Hi Mandy,


On 09/02/2016 05:30 PM, Mandy Chung wrote:
> Constructor::newInstance is a caller-sensitive method that performs the security check when the caller is not the same class loader as implClass?s class loader or not its ancestor.
>
> In this case the caller class is ServerSocket and its class loader is the bootstrap class loader is privileged (an ancestor of any loader).

I'm thinking of the Class::getDeclaredConstructor method.

If the implClass's class loader is not the bootstrap loader, 
"accessDeclaredMembers" permission will be checked. I don't know about 
which implClass(es) will be passed to the method, but if custom user 
classes are among them, they will not be loaded by bootstrap loader, right?

Checking the usages of getDeclaredConstructor() in JDK sources I can see 
that they usually (but not always) are enclosed in doPrivileged.

Regards, Peter

>
> Mandy
>
>> On Sep 2, 2016, at 6:42 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> Hi Many,
>>
>> Are you sure the implementation class passed to JavaNetSocketAccess.newSocketImpl(Class<? extends SocketImpl> implClass) is never going to be loaded by a class loader other than bootstrap classloader (the loader of the caller of implClass.getDeclaredConstructor()) and that no unprivileged code will be on the call stack at that time? Do you need to enclose this invocation into doPrivileged() block or do you expect that the caller of JavaNetSocketAccess.newSocketImpl() will do that?
>>
>> Regards, Peter
>>
>> On 08/31/2016 10:48 PM, Mandy Chung wrote:
>>> This patch introduces JavaNetSocketAccess to allow access to non-public ServerSocket constructor that is accessed by some other area as a clean up.
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165180/webrev.00/
>>>
>>> Mandy


From christoph.langer at sap.com  Mon Sep  5 08:13:26 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 5 Sep 2016 08:13:26 +0000
Subject: Ping: RFR(S): 8163181: Further improvements for Unix
	NetworkInterface native implementation
References: <38c20c4fa4684bee94f9c3e2bb890c7a@DEWDFE13DE11.global.corp.sap>
	<c4c73e06-28c9-ee4c-3f04-436942debd3b@oracle.com>
	<d3a9aaf5-f1fd-b23a-d45d-27e67698d538@oracle.com> 
Message-ID: <c9452c0b65e94bc0affb6538b9ca5771@DEWDFE13DE11.global.corp.sap>

Done: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/40c3550625a2

Thanks for review/testing.

From: Langer, Christoph
Sent: Freitag, 2. September 2016 16:51
To: 'Mark Sheppard' <mark.sheppard at oracle.com>; net-dev at openjdk.java.net
Cc: 'Chris Hegarty' <chris.hegarty at oracle.com>
Subject: RE: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

That's great, thanks.

I'll push on Monday.

Best regards
Christoph

From: Mark Sheppard [mailto:mark.sheppard at oracle.com]
Sent: Freitag, 2. September 2016 16:50
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>
Subject: Re: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation


builds and regression tests appear to be OK with the proposed changes.

regards
Mark
On 02/09/2016 12:41, Mark Sheppard wrote:

have had a look through the changes twice, and they look fine ... i'll apply the patch and run a regression build to confirm

the moving of int flags on 919 to a conditional block,  I expect to cause a strict compile error in my solaris env, so need to check that

regards
Mark
On 02/09/2016 08:22, Langer, Christoph wrote:
Hi (Mark or Chris?),

as this RFR is outstanding for quite a while and it merely is a minor change which only cleans up coding, would you mind to review it that I can get it off my list?

The only major thing probably is, that calls to getMacAddress don't need a socket anymore and sockets are only opened for platforms where an ioctl is done to determine the MacAddress.

As I've said, I've tested it on the Linux/Unix platforms.

Thanks a lot
Christoph

From: Langer, Christoph
Sent: Montag, 22. August 2016 15:30
To: 'net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>' <net-dev at openjdk.java.net><mailto:net-dev at openjdk.java.net>
Subject: RE: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Hi,

I made a little update to my change: http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.2/>

Merely comments and a minor AIX specific correction.

Thanks in advance for reviewing
Christoph


From: Langer, Christoph
Sent: Dienstag, 16. August 2016 14:49
To: 'net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>' <net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>>
Subject: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Ping: Can I get a review for this small set of changes please?

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 4. August 2016 15:04
To: net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>
Subject: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Hi,

I had made a few more cleanups when I was working on NetworkInterface.c which I thought are worth contributing.

Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8163181.1/>
Bug: https://bugs.openjdk.java.net/browse/JDK-8163181

As always, changes were built and tested on Linux, AIX, Solaris and Mac.

Thanks
Christoph



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160905/bbd0a5bb/attachment-0001.html>

From chris.hegarty at oracle.com  Mon Sep  5 11:02:31 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 5 Sep 2016 12:02:31 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
Message-ID: <30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>

Vyom,

 >>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html

There is some concern about the potential performance effect, etc,
of gettimeofday, maybe there is a way out of this. The reuse of
NET_Timeout is good, but it also calls gettimeofday. It seems that
a specific NET_ReadWithTimeout could be written to NOT reuse
NET_Timeout, but effectively inline its interruptible operation.
Or write a variant of NET_Timeout that takes a function to
execute. Rather than effectively two loops conditioned on the
timeout.  Disclaimer: I have not actually tried to do this, but
it seems worth considering / evaluating.

-Chris.

On 02/09/16 04:39, Vyom Tewari wrote:
> hi Dimitry,
>
> thanks for review, I did consider to use  a monotonically increasing
> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
> "gettimeofday"  so i choose to be consistent with the existing code.
>
> Thanks,
>
> Vyom
>
>
> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>> Vyom,
>>
>> Did you consider to use select() to calculate timeout instead of
>> gettimeofday ?
>>
>> gettimeofday is affected by system time changes, so running ntpd can
>> cause unpredictable behavior of this code. Also it's rather expensive
>> syscall.
>>
>> -Dmitry
>>
>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>> please find the updated
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). I
>>> incorporated the review comments.
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>> Hi
>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>> for me a "goto " carries a code smell! )
>>>>
>>>> along the lines
>>>>
>>>> if (timeout) {
>>>>      nread =  NET_ReadWithTimeout(...);
>>>> } else {
>>>>       nread = NET_Read(...);
>>>> }
>>>>
>>>>
>>>> the NET_ReadWithTimeout (...) function will contain a restructuring of
>>>> your goto loop
>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>            if (nread <= 0) {
>>>>                if (nread == 0) {
>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>> "SocketTimeoutException",
>>>>                                "Read timed out");
>>>>                } else if (nread == -1) {
>>>>                    if (errno == EBADF) {
>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>> "SocketException", "Socket closed");
>>>>                    } else if (errno == ENOMEM) {
>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>> native heap allocation failed");
>>>>                    } else {
>>>>                        JNU_ThrowByNameWithMessageAndLastError
>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>> "select/poll failed");
>>>>                    }
>>>>                }
>>>>                  // release buffer in main call flow
>>>> //              if (bufP != BUF) {
>>>> //                  free(bufP);
>>>> //             }
>>>>               nread = -1;
>>>>               break;
>>>>            } else {
>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>                gettimeofday(&t, NULL);
>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>> _timeout -= newtime - prevtime;
>>>> if(_timeout > 0){
>>>> prevtime = newtime;
>>>>                    }
>>>> } else { break; } } } return nread;
>>>>
>>>> e&oe
>>>>
>>>> regards
>>>> Mark
>>>>
>>>>
>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>> gentle reminder, please review the below code change.
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the code changes for below issue.
>>>>>>
>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>
>>>>>> webrev    :
>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>
>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>> "soTimeout" set.the implementation of
>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>> won't block after poll() reports that a read is possible.
>>>>>>
>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>> nevertheless a subsequent read blocks. This could for example happen
>>>>>> when data has arrived but upon examination has wrong checksum and is
>>>>>> discarded.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>
>

From mark.sheppard at oracle.com  Mon Sep  5 14:37:54 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 5 Sep 2016 15:37:54 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
Message-ID: <2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>


if the desire is to avoid making double calls on gettimeofday in the 
NET_ReadWithTimeout's while loop for its main call flow,
then consider a modification to NET_Timeout and create a version
int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval * 
current_time)

int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval * 
current_time) {
     int result;
     struct timeval t;
     long prevtime, newtime;
     struct pollfd pfd;
     pfd.fd = s;
     pfd.events = POLLIN;

     if (timeout > 0) {
         prevtime = (current_time->tv_sec * 1000)  + 
current_time->tv_usec / 1000;
     }

     for(;;) {
         result = poll(&pfd, 1, timeout);
         if (result < 0 && errno == EINTR) {
             if (timeout > 0) {
                 gettimeofday(&t, NULL);
                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
                 timeout -= newtime - prevtime;
                 if (timeout <= 0)
                     return 0;
                 prevtime = newtime;
             }
         } else {
             return result;
         }
     }
}

the NET_ReadWithTimeout is modified with.

    while (timeout > 0) {
         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);

in any case there is the potential for multiple invocation of 
gettimeofday due to a need to make
poll restartable, and adjust the originally specified timeout 
accordingly, and for the edge case
after the non blocking read.

regards
Mark



On 05/09/2016 12:02, Chris Hegarty wrote:
> Vyom,
>
> >>> 
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>
> There is some concern about the potential performance effect, etc,
> of gettimeofday, maybe there is a way out of this. The reuse of
> NET_Timeout is good, but it also calls gettimeofday. It seems that
> a specific NET_ReadWithTimeout could be written to NOT reuse
> NET_Timeout, but effectively inline its interruptible operation.
> Or write a variant of NET_Timeout that takes a function to
> execute. Rather than effectively two loops conditioned on the
> timeout.  Disclaimer: I have not actually tried to do this, but
> it seems worth considering / evaluating.
>
> -Chris.
>
> On 02/09/16 04:39, Vyom Tewari wrote:
>> hi Dimitry,
>>
>> thanks for review, I did consider to use  a monotonically increasing
>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
>> "gettimeofday"  so i choose to be consistent with the existing code.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>> Vyom,
>>>
>>> Did you consider to use select() to calculate timeout instead of
>>> gettimeofday ?
>>>
>>> gettimeofday is affected by system time changes, so running ntpd can
>>> cause unpredictable behavior of this code. Also it's rather expensive
>>> syscall.
>>>
>>> -Dmitry
>>>
>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>> please find the updated
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
>>>> I
>>>> incorporated the review comments.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>> Hi
>>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>>> for me a "goto " carries a code smell! )
>>>>>
>>>>> along the lines
>>>>>
>>>>> if (timeout) {
>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>> } else {
>>>>>       nread = NET_Read(...);
>>>>> }
>>>>>
>>>>>
>>>>> the NET_ReadWithTimeout (...) function will contain a 
>>>>> restructuring of
>>>>> your goto loop
>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>            if (nread <= 0) {
>>>>>                if (nread == 0) {
>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>> "SocketTimeoutException",
>>>>>                                "Read timed out");
>>>>>                } else if (nread == -1) {
>>>>>                    if (errno == EBADF) {
>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>> "SocketException", "Socket closed");
>>>>>                    } else if (errno == ENOMEM) {
>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>> native heap allocation failed");
>>>>>                    } else {
>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>> "select/poll failed");
>>>>>                    }
>>>>>                }
>>>>>                  // release buffer in main call flow
>>>>> //              if (bufP != BUF) {
>>>>> //                  free(bufP);
>>>>> //             }
>>>>>               nread = -1;
>>>>>               break;
>>>>>            } else {
>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>                gettimeofday(&t, NULL);
>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>> _timeout -= newtime - prevtime;
>>>>> if(_timeout > 0){
>>>>> prevtime = newtime;
>>>>>                    }
>>>>> } else { break; } } } return nread;
>>>>>
>>>>> e&oe
>>>>>
>>>>> regards
>>>>> Mark
>>>>>
>>>>>
>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>> gentle reminder, please review the below code change.
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review the code changes for below issue.
>>>>>>>
>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>
>>>>>>> webrev    :
>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html> 
>>>>>>>
>>>>>>>
>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>> "soTimeout" set.the implementation of
>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>
>>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>> nevertheless a subsequent read blocks. This could for example 
>>>>>>> happen
>>>>>>> when data has arrived but upon examination has wrong checksum 
>>>>>>> and is
>>>>>>> discarded.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>
>>


From chris.hegarty at oracle.com  Mon Sep  5 15:07:14 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 5 Sep 2016 16:07:14 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
Message-ID: <71f665aa-8952-8d59-1a81-af996713e301@oracle.com>

On 05/09/16 15:37, Mark Sheppard wrote:
>
> if the desire is to avoid making double calls on gettimeofday in the
> NET_ReadWithTimeout's while loop for its main call flow,

Yes, the desire is to make no more calls to gettimeofday, than are
already done.

> then consider a modification to NET_Timeout and create a version
> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> current_time)
>
> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> current_time) {
>     int result;
>     struct timeval t;
>     long prevtime, newtime;
>     struct pollfd pfd;
>     pfd.fd = s;
>     pfd.events = POLLIN;
>
>     if (timeout > 0) {
>         prevtime = (current_time->tv_sec * 1000)  +
> current_time->tv_usec / 1000;
>     }
>
>     for(;;) {
>         result = poll(&pfd, 1, timeout);
>         if (result < 0 && errno == EINTR) {
>             if (timeout > 0) {
>                 gettimeofday(&t, NULL);
>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>                 timeout -= newtime - prevtime;
>                 if (timeout <= 0)
>                     return 0;
>                 prevtime = newtime;
>             }
>         } else {
>             return result;
>         }
>     }
> }
>
> the NET_ReadWithTimeout is modified with.
>
>    while (timeout > 0) {
>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>
> in any case there is the potential for multiple invocation of
> gettimeofday due to a need to make
> poll restartable,

Yes, and that is fine. Just no more than is already there.

  and adjust the originally specified timeout
> accordingly, and for the edge case
> after the non blocking read.

After an initial skim, your suggestion seems reasonable.

-Chris.

> regards
> Mark
>
>
>
> On 05/09/2016 12:02, Chris Hegarty wrote:
>> Vyom,
>>
>> >>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>
>> There is some concern about the potential performance effect, etc,
>> of gettimeofday, maybe there is a way out of this. The reuse of
>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>> a specific NET_ReadWithTimeout could be written to NOT reuse
>> NET_Timeout, but effectively inline its interruptible operation.
>> Or write a variant of NET_Timeout that takes a function to
>> execute. Rather than effectively two loops conditioned on the
>> timeout.  Disclaimer: I have not actually tried to do this, but
>> it seems worth considering / evaluating.
>>
>> -Chris.
>>
>> On 02/09/16 04:39, Vyom Tewari wrote:
>>> hi Dimitry,
>>>
>>> thanks for review, I did consider to use  a monotonically increasing
>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>> Vyom,
>>>>
>>>> Did you consider to use select() to calculate timeout instead of
>>>> gettimeofday ?
>>>>
>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>> syscall.
>>>>
>>>> -Dmitry
>>>>
>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>> please find the updated
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>> I
>>>>> incorporated the review comments.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>> Hi
>>>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>>>> for me a "goto " carries a code smell! )
>>>>>>
>>>>>> along the lines
>>>>>>
>>>>>> if (timeout) {
>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>> } else {
>>>>>>       nread = NET_Read(...);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>> restructuring of
>>>>>> your goto loop
>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>            if (nread <= 0) {
>>>>>>                if (nread == 0) {
>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>> "SocketTimeoutException",
>>>>>>                                "Read timed out");
>>>>>>                } else if (nread == -1) {
>>>>>>                    if (errno == EBADF) {
>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>> "SocketException", "Socket closed");
>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>> native heap allocation failed");
>>>>>>                    } else {
>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>> "select/poll failed");
>>>>>>                    }
>>>>>>                }
>>>>>>                  // release buffer in main call flow
>>>>>> //              if (bufP != BUF) {
>>>>>> //                  free(bufP);
>>>>>> //             }
>>>>>>               nread = -1;
>>>>>>               break;
>>>>>>            } else {
>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>                gettimeofday(&t, NULL);
>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>> _timeout -= newtime - prevtime;
>>>>>> if(_timeout > 0){
>>>>>> prevtime = newtime;
>>>>>>                    }
>>>>>> } else { break; } } } return nread;
>>>>>>
>>>>>> e&oe
>>>>>>
>>>>>> regards
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>> gentle reminder, please review the below code change.
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review the code changes for below issue.
>>>>>>>>
>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>
>>>>>>>> webrev    :
>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>
>>>>>>>>
>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>
>>>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>> happen
>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>> and is
>>>>>>>> discarded.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>
>>>
>

From vyom.tewari at oracle.com  Tue Sep  6 09:20:56 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 6 Sep 2016 14:50:56 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
Message-ID: <ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>

Hi,

Please find the latest 
webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I 
have incorporated the review comments.

Thanks,

Vyom


On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> On 05/09/16 15:37, Mark Sheppard wrote:
>>
>> if the desire is to avoid making double calls on gettimeofday in the
>> NET_ReadWithTimeout's while loop for its main call flow,
>
> Yes, the desire is to make no more calls to gettimeofday, than are
> already done.
>
>> then consider a modification to NET_Timeout and create a version
>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>> current_time)
>>
>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>> current_time) {
>>     int result;
>>     struct timeval t;
>>     long prevtime, newtime;
>>     struct pollfd pfd;
>>     pfd.fd = s;
>>     pfd.events = POLLIN;
>>
>>     if (timeout > 0) {
>>         prevtime = (current_time->tv_sec * 1000)  +
>> current_time->tv_usec / 1000;
>>     }
>>
>>     for(;;) {
>>         result = poll(&pfd, 1, timeout);
>>         if (result < 0 && errno == EINTR) {
>>             if (timeout > 0) {
>>                 gettimeofday(&t, NULL);
>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>                 timeout -= newtime - prevtime;
>>                 if (timeout <= 0)
>>                     return 0;
>>                 prevtime = newtime;
>>             }
>>         } else {
>>             return result;
>>         }
>>     }
>> }
>>
>> the NET_ReadWithTimeout is modified with.
>>
>>    while (timeout > 0) {
>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>
>> in any case there is the potential for multiple invocation of
>> gettimeofday due to a need to make
>> poll restartable,
>
> Yes, and that is fine. Just no more than is already there.
>
>  and adjust the originally specified timeout
>> accordingly, and for the edge case
>> after the non blocking read.
>
> After an initial skim, your suggestion seems reasonable.
>
> -Chris.
>
>> regards
>> Mark
>>
>>
>>
>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>> Vyom,
>>>
>>> >>>
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>
>>> There is some concern about the potential performance effect, etc,
>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>> NET_Timeout, but effectively inline its interruptible operation.
>>> Or write a variant of NET_Timeout that takes a function to
>>> execute. Rather than effectively two loops conditioned on the
>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>> it seems worth considering / evaluating.
>>>
>>> -Chris.
>>>
>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>> hi Dimitry,
>>>>
>>>> thanks for review, I did consider to use  a monotonically increasing
>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") 
>>>> uses
>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>> Vyom,
>>>>>
>>>>> Did you consider to use select() to calculate timeout instead of
>>>>> gettimeofday ?
>>>>>
>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>>> syscall.
>>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>> please find the updated
>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>>
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
>>>>>>
>>>>>> I
>>>>>> incorporated the review comments.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>> Hi
>>>>>>>    perhaps there is an opportunity to do  some refactoring here 
>>>>>>> (...
>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>
>>>>>>> along the lines
>>>>>>>
>>>>>>> if (timeout) {
>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>> } else {
>>>>>>>       nread = NET_Read(...);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>> restructuring of
>>>>>>> your goto loop
>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>            if (nread <= 0) {
>>>>>>>                if (nread == 0) {
>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>> "SocketTimeoutException",
>>>>>>>                                "Read timed out");
>>>>>>>                } else if (nread == -1) {
>>>>>>>                    if (errno == EBADF) {
>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>> "SocketException", "Socket closed");
>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>> native heap allocation failed");
>>>>>>>                    } else {
>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>>> "select/poll failed");
>>>>>>>                    }
>>>>>>>                }
>>>>>>>                  // release buffer in main call flow
>>>>>>> //              if (bufP != BUF) {
>>>>>>> //                  free(bufP);
>>>>>>> //             }
>>>>>>>               nread = -1;
>>>>>>>               break;
>>>>>>>            } else {
>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>>                gettimeofday(&t, NULL);
>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>> _timeout -= newtime - prevtime;
>>>>>>> if(_timeout > 0){
>>>>>>> prevtime = newtime;
>>>>>>>                    }
>>>>>>> } else { break; } } } return nread;
>>>>>>>
>>>>>>> e&oe
>>>>>>>
>>>>>>> regards
>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>
>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>
>>>>>>>>> webrev    :
>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>
>>>>>>>>> This assumption does not hold, as noted on the man page for 
>>>>>>>>> select
>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>> happen
>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>> and is
>>>>>>>>> discarded.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>
>>


From mark.sheppard at oracle.com  Tue Sep  6 11:49:32 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 6 Sep 2016 12:49:32 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
Message-ID: <f9d31b73-6519-bd2d-a5f3-4cbac70350a3@oracle.com>


looks fine ... thanks

regards
Mark

On 06/09/2016 10:20, Vyom Tewari wrote:
> Hi,
>
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html 
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). 
> I have incorporated the review comments.
>
> Thanks,
>
> Vyom
>
>
> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>
>>> if the desire is to avoid making double calls on gettimeofday in the
>>> NET_ReadWithTimeout's while loop for its main call flow,
>>
>> Yes, the desire is to make no more calls to gettimeofday, than are
>> already done.
>>
>>> then consider a modification to NET_Timeout and create a version
>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>> current_time)
>>>
>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>> current_time) {
>>>     int result;
>>>     struct timeval t;
>>>     long prevtime, newtime;
>>>     struct pollfd pfd;
>>>     pfd.fd = s;
>>>     pfd.events = POLLIN;
>>>
>>>     if (timeout > 0) {
>>>         prevtime = (current_time->tv_sec * 1000)  +
>>> current_time->tv_usec / 1000;
>>>     }
>>>
>>>     for(;;) {
>>>         result = poll(&pfd, 1, timeout);
>>>         if (result < 0 && errno == EINTR) {
>>>             if (timeout > 0) {
>>>                 gettimeofday(&t, NULL);
>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>                 timeout -= newtime - prevtime;
>>>                 if (timeout <= 0)
>>>                     return 0;
>>>                 prevtime = newtime;
>>>             }
>>>         } else {
>>>             return result;
>>>         }
>>>     }
>>> }
>>>
>>> the NET_ReadWithTimeout is modified with.
>>>
>>>    while (timeout > 0) {
>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>
>>> in any case there is the potential for multiple invocation of
>>> gettimeofday due to a need to make
>>> poll restartable,
>>
>> Yes, and that is fine. Just no more than is already there.
>>
>>  and adjust the originally specified timeout
>>> accordingly, and for the edge case
>>> after the non blocking read.
>>
>> After an initial skim, your suggestion seems reasonable.
>>
>> -Chris.
>>
>>> regards
>>> Mark
>>>
>>>
>>>
>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>> Vyom,
>>>>
>>>> >>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>
>>>>
>>>> There is some concern about the potential performance effect, etc,
>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>> Or write a variant of NET_Timeout that takes a function to
>>>> execute. Rather than effectively two loops conditioned on the
>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>> it seems worth considering / evaluating.
>>>>
>>>> -Chris.
>>>>
>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>> hi Dimitry,
>>>>>
>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>> clock like "clock_gettime" but  existing nearby 
>>>>> code("NET_Timeout") uses
>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>> Vyom,
>>>>>>
>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>> gettimeofday ?
>>>>>>
>>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>>> cause unpredictable behavior of this code. Also it's rather 
>>>>>> expensive
>>>>>> syscall.
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>> please find the updated
>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>>>
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
>>>>>>>
>>>>>>> I
>>>>>>> incorporated the review comments.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>> Hi
>>>>>>>>    perhaps there is an opportunity to do  some refactoring here 
>>>>>>>> (...
>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>
>>>>>>>> along the lines
>>>>>>>>
>>>>>>>> if (timeout) {
>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>> } else {
>>>>>>>>       nread = NET_Read(...);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>> restructuring of
>>>>>>>> your goto loop
>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>            if (nread <= 0) {
>>>>>>>>                if (nread == 0) {
>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>> "SocketTimeoutException",
>>>>>>>>                                "Read timed out");
>>>>>>>>                } else if (nread == -1) {
>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>> JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>> native heap allocation failed");
>>>>>>>>                    } else {
>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>>>> "select/poll failed");
>>>>>>>>                    }
>>>>>>>>                }
>>>>>>>>                  // release buffer in main call flow
>>>>>>>> //              if (bufP != BUF) {
>>>>>>>> //                  free(bufP);
>>>>>>>> //             }
>>>>>>>>               nread = -1;
>>>>>>>>               break;
>>>>>>>>            } else {
>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == 
>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>> if(_timeout > 0){
>>>>>>>> prevtime = newtime;
>>>>>>>>                    }
>>>>>>>> } else { break; } } } return nread;
>>>>>>>>
>>>>>>>> e&oe
>>>>>>>>
>>>>>>>> regards
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>
>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>
>>>>>>>>>> webrev    :
>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>
>>>>>>>>>> This assumption does not hold, as noted on the man page for 
>>>>>>>>>> select
>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>> happen
>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>> and is
>>>>>>>>>> discarded.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>
>>>
>


From dmitry.samersoff at oracle.com  Tue Sep  6 12:38:22 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 6 Sep 2016 15:38:22 +0300
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
Message-ID: <1806dfaf-cf6b-57f6-3d12-a9f52874c375@oracle.com>

Vyom,

Looks good for me!

SocketInputStream.c:68

It's better to check for both EAGAIN and EINTR after poll()

(no need to re-review).

-Dmitry


On 2016-09-06 12:20, Vyom Tewari wrote:
> Hi,
> 
> Please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I
> have incorporated the review comments.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>
>>> if the desire is to avoid making double calls on gettimeofday in the
>>> NET_ReadWithTimeout's while loop for its main call flow,
>>
>> Yes, the desire is to make no more calls to gettimeofday, than are
>> already done.
>>
>>> then consider a modification to NET_Timeout and create a version
>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>> current_time)
>>>
>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>> current_time) {
>>>     int result;
>>>     struct timeval t;
>>>     long prevtime, newtime;
>>>     struct pollfd pfd;
>>>     pfd.fd = s;
>>>     pfd.events = POLLIN;
>>>
>>>     if (timeout > 0) {
>>>         prevtime = (current_time->tv_sec * 1000)  +
>>> current_time->tv_usec / 1000;
>>>     }
>>>
>>>     for(;;) {
>>>         result = poll(&pfd, 1, timeout);
>>>         if (result < 0 && errno == EINTR) {
>>>             if (timeout > 0) {
>>>                 gettimeofday(&t, NULL);
>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>                 timeout -= newtime - prevtime;
>>>                 if (timeout <= 0)
>>>                     return 0;
>>>                 prevtime = newtime;
>>>             }
>>>         } else {
>>>             return result;
>>>         }
>>>     }
>>> }
>>>
>>> the NET_ReadWithTimeout is modified with.
>>>
>>>    while (timeout > 0) {
>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>
>>> in any case there is the potential for multiple invocation of
>>> gettimeofday due to a need to make
>>> poll restartable,
>>
>> Yes, and that is fine. Just no more than is already there.
>>
>>  and adjust the originally specified timeout
>>> accordingly, and for the edge case
>>> after the non blocking read.
>>
>> After an initial skim, your suggestion seems reasonable.
>>
>> -Chris.
>>
>>> regards
>>> Mark
>>>
>>>
>>>
>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>> Vyom,
>>>>
>>>> >>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>
>>>> There is some concern about the potential performance effect, etc,
>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>> Or write a variant of NET_Timeout that takes a function to
>>>> execute. Rather than effectively two loops conditioned on the
>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>> it seems worth considering / evaluating.
>>>>
>>>> -Chris.
>>>>
>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>> hi Dimitry,
>>>>>
>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout")
>>>>> uses
>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>> Vyom,
>>>>>>
>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>> gettimeofday ?
>>>>>>
>>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>>>> syscall.
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>> please find the updated
>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>
>>>>>>> I
>>>>>>> incorporated the review comments.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>> Hi
>>>>>>>>    perhaps there is an opportunity to do  some refactoring here
>>>>>>>> (...
>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>
>>>>>>>> along the lines
>>>>>>>>
>>>>>>>> if (timeout) {
>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>> } else {
>>>>>>>>       nread = NET_Read(...);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>> restructuring of
>>>>>>>> your goto loop
>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>            if (nread <= 0) {
>>>>>>>>                if (nread == 0) {
>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>> "SocketTimeoutException",
>>>>>>>>                                "Read timed out");
>>>>>>>>                } else if (nread == -1) {
>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>> native heap allocation failed");
>>>>>>>>                    } else {
>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>>>> "select/poll failed");
>>>>>>>>                    }
>>>>>>>>                }
>>>>>>>>                  // release buffer in main call flow
>>>>>>>> //              if (bufP != BUF) {
>>>>>>>> //                  free(bufP);
>>>>>>>> //             }
>>>>>>>>               nread = -1;
>>>>>>>>               break;
>>>>>>>>            } else {
>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>> if(_timeout > 0){
>>>>>>>> prevtime = newtime;
>>>>>>>>                    }
>>>>>>>> } else { break; } } } return nread;
>>>>>>>>
>>>>>>>> e&oe
>>>>>>>>
>>>>>>>> regards
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>
>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>
>>>>>>>>>> webrev    :
>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>
>>>>>>>>>> This assumption does not hold, as noted on the man page for
>>>>>>>>>> select
>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>> happen
>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>> and is
>>>>>>>>>> discarded.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>
>>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From chris.hegarty at oracle.com  Tue Sep  6 12:55:49 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 6 Sep 2016 13:55:49 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
Message-ID: <631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>

Vyom,

> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi,
> 
> Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I have incorporated the review comments.

Your changes completely avoid NET_Timeout, which is quite complex on 
Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
async close mechanism to signal/interrupt a thread blocked in a poll / 
select ). Also, select is used on Mac, which will use poll after your
changes ( I do remember that there was a bug in poll on Mac around
the time of the original Mac port ).

Would is be better, rather than replicating the logic in  NET_Timeout,
to have a version that supports passing a function pointer, to run if
the poll/select returns before the timeout? Just an idea.

-Chris.

> Thanks,
> 
> Vyom
> 
> 
> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>> On 05/09/16 15:37, Mark Sheppard wrote:
>>> 
>>> if the desire is to avoid making double calls on gettimeofday in the
>>> NET_ReadWithTimeout's while loop for its main call flow,
>> 
>> Yes, the desire is to make no more calls to gettimeofday, than are
>> already done.
>> 
>>> then consider a modification to NET_Timeout and create a version
>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>> current_time)
>>> 
>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>> current_time) {
>>>    int result;
>>>    struct timeval t;
>>>    long prevtime, newtime;
>>>    struct pollfd pfd;
>>>    pfd.fd = s;
>>>    pfd.events = POLLIN;
>>> 
>>>    if (timeout > 0) {
>>>        prevtime = (current_time->tv_sec * 1000)  +
>>> current_time->tv_usec / 1000;
>>>    }
>>> 
>>>    for(;;) {
>>>        result = poll(&pfd, 1, timeout);
>>>        if (result < 0 && errno == EINTR) {
>>>            if (timeout > 0) {
>>>                gettimeofday(&t, NULL);
>>>                newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>                timeout -= newtime - prevtime;
>>>                if (timeout <= 0)
>>>                    return 0;
>>>                prevtime = newtime;
>>>            }
>>>        } else {
>>>            return result;
>>>        }
>>>    }
>>> }
>>> 
>>> the NET_ReadWithTimeout is modified with.
>>> 
>>>   while (timeout > 0) {
>>>        result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>> 
>>> in any case there is the potential for multiple invocation of
>>> gettimeofday due to a need to make
>>> poll restartable,
>> 
>> Yes, and that is fine. Just no more than is already there.
>> 
>> and adjust the originally specified timeout
>>> accordingly, and for the edge case
>>> after the non blocking read.
>> 
>> After an initial skim, your suggestion seems reasonable.
>> 
>> -Chris.
>> 
>>> regards
>>> Mark
>>> 
>>> 
>>> 
>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>> Vyom,
>>>> 
>>>> >>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>> 
>>>> There is some concern about the potential performance effect, etc,
>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>> Or write a variant of NET_Timeout that takes a function to
>>>> execute. Rather than effectively two loops conditioned on the
>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>> it seems worth considering / evaluating.
>>>> 
>>>> -Chris.
>>>> 
>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>> hi Dimitry,
>>>>> 
>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Vyom
>>>>> 
>>>>> 
>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>> Vyom,
>>>>>> 
>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>> gettimeofday ?
>>>>>> 
>>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>>>> syscall.
>>>>>> 
>>>>>> -Dmitry
>>>>>> 
>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>> please find the updated
>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>>> 
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
>>>>>>> I
>>>>>>> incorporated the review comments.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Vyom
>>>>>>> 
>>>>>>> 
>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>> Hi
>>>>>>>>   perhaps there is an opportunity to do  some refactoring here (...
>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>> 
>>>>>>>> along the lines
>>>>>>>> 
>>>>>>>> if (timeout) {
>>>>>>>>     nread =  NET_ReadWithTimeout(...);
>>>>>>>> } else {
>>>>>>>>      nread = NET_Read(...);
>>>>>>>> }
>>>>>>>> 
>>>>>>>> 
>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>> restructuring of
>>>>>>>> your goto loop
>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>           if (nread <= 0) {
>>>>>>>>               if (nread == 0) {
>>>>>>>>                   JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>> "SocketTimeoutException",
>>>>>>>>                               "Read timed out");
>>>>>>>>               } else if (nread == -1) {
>>>>>>>>                   if (errno == EBADF) {
>>>>>>>>                        JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>                   } else if (errno == ENOMEM) {
>>>>>>>>                       JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>> native heap allocation failed");
>>>>>>>>                   } else {
>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>                           (env, JNU_JAVANETPKG "SocketException",
>>>>>>>> "select/poll failed");
>>>>>>>>                   }
>>>>>>>>               }
>>>>>>>>                 // release buffer in main call flow
>>>>>>>> //              if (bufP != BUF) {
>>>>>>>> //                  free(bufP);
>>>>>>>> //             }
>>>>>>>>              nread = -1;
>>>>>>>>              break;
>>>>>>>>           } else {
>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>>>               gettimeofday(&t, NULL);
>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>> if(_timeout > 0){
>>>>>>>> prevtime = newtime;
>>>>>>>>                   }
>>>>>>>> } else { break; } } } return nread;
>>>>>>>> 
>>>>>>>> e&oe
>>>>>>>> 
>>>>>>>> regards
>>>>>>>> Mark
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>> 
>>>>>>>>> Vyom
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> 
>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>> 
>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>> 
>>>>>>>>>> webrev    :
>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>> 
>>>>>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>> happen
>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>> and is
>>>>>>>>>> discarded.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Vyom
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>> 
>>>>> 
>>> 
> 


From vyom.tewari at oracle.com  Tue Sep  6 13:02:17 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 6 Sep 2016 18:32:17 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
Message-ID: <567cd2d9-92fb-e078-bc13-132e6bb3868b@oracle.com>



On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> Vyom,
>
>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I have incorporated the review comments.
> Your changes completely avoid NET_Timeout, which is quite complex on
> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> async close mechanism to signal/interrupt a thread blocked in a poll /
> select ). Also, select is used on Mac, which will use poll after your
> changes ( I do remember that there was a bug in poll on Mac around
> the time of the original Mac port ).
that is why , in webrev0.1 i was re using the NET_Timeout.
>
> Would is be better, rather than replicating the logic in  NET_Timeout,
> to have a version that supports passing a function pointer, to run if
> the poll/select returns before the timeout? Just an idea.
let me try out if it works.

Thanks,
Vyom
> -Chris.
>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>> already done.
>>>
>>>> then consider a modification to NET_Timeout and create a version
>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>> current_time)
>>>>
>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>> current_time) {
>>>>     int result;
>>>>     struct timeval t;
>>>>     long prevtime, newtime;
>>>>     struct pollfd pfd;
>>>>     pfd.fd = s;
>>>>     pfd.events = POLLIN;
>>>>
>>>>     if (timeout > 0) {
>>>>         prevtime = (current_time->tv_sec * 1000)  +
>>>> current_time->tv_usec / 1000;
>>>>     }
>>>>
>>>>     for(;;) {
>>>>         result = poll(&pfd, 1, timeout);
>>>>         if (result < 0 && errno == EINTR) {
>>>>             if (timeout > 0) {
>>>>                 gettimeofday(&t, NULL);
>>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>>                 timeout -= newtime - prevtime;
>>>>                 if (timeout <= 0)
>>>>                     return 0;
>>>>                 prevtime = newtime;
>>>>             }
>>>>         } else {
>>>>             return result;
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> the NET_ReadWithTimeout is modified with.
>>>>
>>>>    while (timeout > 0) {
>>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>
>>>> in any case there is the potential for multiple invocation of
>>>> gettimeofday due to a need to make
>>>> poll restartable,
>>> Yes, and that is fine. Just no more than is already there.
>>>
>>> and adjust the originally specified timeout
>>>> accordingly, and for the edge case
>>>> after the non blocking read.
>>> After an initial skim, your suggestion seems reasonable.
>>>
>>> -Chris.
>>>
>>>> regards
>>>> Mark
>>>>
>>>>
>>>>
>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>> Vyom,
>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>
>>>>> There is some concern about the potential performance effect, etc,
>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>> execute. Rather than effectively two loops conditioned on the
>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>> it seems worth considering / evaluating.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>> hi Dimitry,
>>>>>>
>>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
>>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>> Vyom,
>>>>>>>
>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>> gettimeofday ?
>>>>>>>
>>>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>>>>> syscall.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>> please find the updated
>>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>> I
>>>>>>>> incorporated the review comments.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>> Hi
>>>>>>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>
>>>>>>>>> along the lines
>>>>>>>>>
>>>>>>>>> if (timeout) {
>>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>>> } else {
>>>>>>>>>       nread = NET_Read(...);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>> restructuring of
>>>>>>>>> your goto loop
>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>            if (nread <= 0) {
>>>>>>>>>                if (nread == 0) {
>>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>                                "Read timed out");
>>>>>>>>>                } else if (nread == -1) {
>>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>>> native heap allocation failed");
>>>>>>>>>                    } else {
>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>>>>> "select/poll failed");
>>>>>>>>>                    }
>>>>>>>>>                }
>>>>>>>>>                  // release buffer in main call flow
>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>> //                  free(bufP);
>>>>>>>>> //             }
>>>>>>>>>               nread = -1;
>>>>>>>>>               break;
>>>>>>>>>            } else {
>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>> if(_timeout > 0){
>>>>>>>>> prevtime = newtime;
>>>>>>>>>                    }
>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>
>>>>>>>>> e&oe
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>
>>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>
>>>>>>>>>>> webrev    :
>>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>
>>>>>>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>>> happen
>>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>>> and is
>>>>>>>>>>> discarded.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Vyom
>>>>>>>>>>>
>>>>>>>>>>>


From mark.sheppard at oracle.com  Tue Sep  6 14:41:46 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 6 Sep 2016 15:41:46 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
Message-ID: <c9a27a3b-108f-dc5b-9de1-e1fd460005a5@oracle.com>


my error ... i perceived NET_Timeout as a common function across all 
platforms
otherwise I would have suggested a NET_TimeoutWithCurrentTime for each 
platform.

providing a version of NET_Timeout with a recv function sound good, but
will require a version per platform (NET_TimeoutWithRecv) and such as a 
change will affect the network
code more extensively, otherwise you need to retain the NET_Timeout 
also,  as it is used in other part of native network.

This change is focused on SocketInputStream, but that is not only place 
where NET_Timeout is called.

either way there is the possibility of replicated code

regards
Mark






On 06/09/2016 13:55, Chris Hegarty wrote:
> Vyom,
>
>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I have incorporated the review comments.
> Your changes completely avoid NET_Timeout, which is quite complex on
> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> async close mechanism to signal/interrupt a thread blocked in a poll /
> select ). Also, select is used on Mac, which will use poll after your
> changes ( I do remember that there was a bug in poll on Mac around
> the time of the original Mac port ).
>
> Would is be better, rather than replicating the logic in  NET_Timeout,
> to have a version that supports passing a function pointer, to run if
> the poll/select returns before the timeout? Just an idea.
>
> -Chris.
>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>> already done.
>>>
>>>> then consider a modification to NET_Timeout and create a version
>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>> current_time)
>>>>
>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>> current_time) {
>>>>     int result;
>>>>     struct timeval t;
>>>>     long prevtime, newtime;
>>>>     struct pollfd pfd;
>>>>     pfd.fd = s;
>>>>     pfd.events = POLLIN;
>>>>
>>>>     if (timeout > 0) {
>>>>         prevtime = (current_time->tv_sec * 1000)  +
>>>> current_time->tv_usec / 1000;
>>>>     }
>>>>
>>>>     for(;;) {
>>>>         result = poll(&pfd, 1, timeout);
>>>>         if (result < 0 && errno == EINTR) {
>>>>             if (timeout > 0) {
>>>>                 gettimeofday(&t, NULL);
>>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>>                 timeout -= newtime - prevtime;
>>>>                 if (timeout <= 0)
>>>>                     return 0;
>>>>                 prevtime = newtime;
>>>>             }
>>>>         } else {
>>>>             return result;
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> the NET_ReadWithTimeout is modified with.
>>>>
>>>>    while (timeout > 0) {
>>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>
>>>> in any case there is the potential for multiple invocation of
>>>> gettimeofday due to a need to make
>>>> poll restartable,
>>> Yes, and that is fine. Just no more than is already there.
>>>
>>> and adjust the originally specified timeout
>>>> accordingly, and for the edge case
>>>> after the non blocking read.
>>> After an initial skim, your suggestion seems reasonable.
>>>
>>> -Chris.
>>>
>>>> regards
>>>> Mark
>>>>
>>>>
>>>>
>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>> Vyom,
>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>
>>>>> There is some concern about the potential performance effect, etc,
>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>> execute. Rather than effectively two loops conditioned on the
>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>> it seems worth considering / evaluating.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>> hi Dimitry,
>>>>>>
>>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
>>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>> Vyom,
>>>>>>>
>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>> gettimeofday ?
>>>>>>>
>>>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>>>>> syscall.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>> please find the updated
>>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>> I
>>>>>>>> incorporated the review comments.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>> Hi
>>>>>>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>
>>>>>>>>> along the lines
>>>>>>>>>
>>>>>>>>> if (timeout) {
>>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>>> } else {
>>>>>>>>>       nread = NET_Read(...);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>> restructuring of
>>>>>>>>> your goto loop
>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>            if (nread <= 0) {
>>>>>>>>>                if (nread == 0) {
>>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>                                "Read timed out");
>>>>>>>>>                } else if (nread == -1) {
>>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>>> native heap allocation failed");
>>>>>>>>>                    } else {
>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>>>>> "select/poll failed");
>>>>>>>>>                    }
>>>>>>>>>                }
>>>>>>>>>                  // release buffer in main call flow
>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>> //                  free(bufP);
>>>>>>>>> //             }
>>>>>>>>>               nread = -1;
>>>>>>>>>               break;
>>>>>>>>>            } else {
>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>> if(_timeout > 0){
>>>>>>>>> prevtime = newtime;
>>>>>>>>>                    }
>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>
>>>>>>>>> e&oe
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>
>>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>
>>>>>>>>>>> webrev    :
>>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>
>>>>>>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>>> happen
>>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>>> and is
>>>>>>>>>>> discarded.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Vyom
>>>>>>>>>>>
>>>>>>>>>>>


From mandy.chung at oracle.com  Tue Sep  6 16:44:10 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 6 Sep 2016 09:44:10 -0700
Subject: Review request JDK-8165180: Provide a shared secret to access
	non-public ServerSocket constructor
In-Reply-To: <f211de88-02e8-c4da-e7c2-47bf2411631a@gmail.com>
References: <04FC0599-A760-4C3F-BE15-D35C6FE6CEC6@oracle.com>
	<14eb81ac-efdb-4f58-ff2d-3fcdd798d7fb@gmail.com>
	<18A33B58-0625-4D30-B4E6-246CD6E00903@oracle.com>
	<f211de88-02e8-c4da-e7c2-47bf2411631a@gmail.com>
Message-ID: <45290C3B-A32F-46D1-9F35-EC14FD2FAEF9@oracle.com>


> On Sep 5, 2016, at 12:19 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> I'm thinking of the Class::getDeclaredConstructor method.
> 
> If the implClass's class loader is not the bootstrap loader, "accessDeclaredMembers" permission will be checked. I don't know about which implClass(es) will be passed to the method, but if custom user classes are among them, they will not be loaded by bootstrap loader, right?

Yes, you?re right.  I expect that the caller should call JavaNetSocketAccess::newSocketImpl with doPrivileged and itself has the proper permission.

Mandy

From vyom.tewari at oracle.com  Wed Sep  7 06:45:50 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 7 Sep 2016 12:15:50 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
Message-ID: <db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>

Hi Chris,

Please find the latest 
webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I 
did some code refactoring, JPRT is in progress.

I need help from some one to build and test latest changes on AIX, may 
be Christoph can help.

Thanks,

Vyom


On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> Vyom,
>
>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I have incorporated the review comments.
> Your changes completely avoid NET_Timeout, which is quite complex on
> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> async close mechanism to signal/interrupt a thread blocked in a poll /
> select ). Also, select is used on Mac, which will use poll after your
> changes ( I do remember that there was a bug in poll on Mac around
> the time of the original Mac port ).
>
> Would is be better, rather than replicating the logic in  NET_Timeout,
> to have a version that supports passing a function pointer, to run if
> the poll/select returns before the timeout? Just an idea.
>
> -Chris.
>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>> already done.
>>>
>>>> then consider a modification to NET_Timeout and create a version
>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>> current_time)
>>>>
>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>> current_time) {
>>>>     int result;
>>>>     struct timeval t;
>>>>     long prevtime, newtime;
>>>>     struct pollfd pfd;
>>>>     pfd.fd = s;
>>>>     pfd.events = POLLIN;
>>>>
>>>>     if (timeout > 0) {
>>>>         prevtime = (current_time->tv_sec * 1000)  +
>>>> current_time->tv_usec / 1000;
>>>>     }
>>>>
>>>>     for(;;) {
>>>>         result = poll(&pfd, 1, timeout);
>>>>         if (result < 0 && errno == EINTR) {
>>>>             if (timeout > 0) {
>>>>                 gettimeofday(&t, NULL);
>>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>>                 timeout -= newtime - prevtime;
>>>>                 if (timeout <= 0)
>>>>                     return 0;
>>>>                 prevtime = newtime;
>>>>             }
>>>>         } else {
>>>>             return result;
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> the NET_ReadWithTimeout is modified with.
>>>>
>>>>    while (timeout > 0) {
>>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>
>>>> in any case there is the potential for multiple invocation of
>>>> gettimeofday due to a need to make
>>>> poll restartable,
>>> Yes, and that is fine. Just no more than is already there.
>>>
>>> and adjust the originally specified timeout
>>>> accordingly, and for the edge case
>>>> after the non blocking read.
>>> After an initial skim, your suggestion seems reasonable.
>>>
>>> -Chris.
>>>
>>>> regards
>>>> Mark
>>>>
>>>>
>>>>
>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>> Vyom,
>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>
>>>>> There is some concern about the potential performance effect, etc,
>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>> execute. Rather than effectively two loops conditioned on the
>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>> it seems worth considering / evaluating.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>> hi Dimitry,
>>>>>>
>>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout") uses
>>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>> Vyom,
>>>>>>>
>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>> gettimeofday ?
>>>>>>>
>>>>>>> gettimeofday is affected by system time changes, so running ntpd can
>>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
>>>>>>> syscall.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>> please find the updated
>>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>> I
>>>>>>>> incorporated the review comments.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>> Hi
>>>>>>>>>    perhaps there is an opportunity to do  some refactoring here (...
>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>
>>>>>>>>> along the lines
>>>>>>>>>
>>>>>>>>> if (timeout) {
>>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>>> } else {
>>>>>>>>>       nread = NET_Read(...);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>> restructuring of
>>>>>>>>> your goto loop
>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>            if (nread <= 0) {
>>>>>>>>>                if (nread == 0) {
>>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>                                "Read timed out");
>>>>>>>>>                } else if (nread == -1) {
>>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>>> native heap allocation failed");
>>>>>>>>>                    } else {
>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
>>>>>>>>> "select/poll failed");
>>>>>>>>>                    }
>>>>>>>>>                }
>>>>>>>>>                  // release buffer in main call flow
>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>> //                  free(bufP);
>>>>>>>>> //             }
>>>>>>>>>               nread = -1;
>>>>>>>>>               break;
>>>>>>>>>            } else {
>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) {
>>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>> if(_timeout > 0){
>>>>>>>>> prevtime = newtime;
>>>>>>>>>                    }
>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>
>>>>>>>>> e&oe
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>
>>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>
>>>>>>>>>>> webrev    :
>>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>
>>>>>>>>>>> This assumption does not hold, as noted on the man page for select
>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>>> happen
>>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>>> and is
>>>>>>>>>>> discarded.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Vyom
>>>>>>>>>>>
>>>>>>>>>>>


From christoph.langer at sap.com  Wed Sep  7 09:19:44 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 7 Sep 2016 09:19:44 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
Message-ID: <cb4031c0f7b64d89baf805d068b4a4b8@DEWDFE13DE11.global.corp.sap>

Hi Vyom,

I'll do an AIX build with your patch and let you know later today.

Best regards
Christoph

> -----Original Message-----
> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Vyom
> Tewari
> Sent: Mittwoch, 7. September 2016 08:46
> To: Chris Hegarty <chris.hegarty at oracle.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Hi Chris,
> 
> Please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
> did some code refactoring, JPRT is in progress.
> 
> I need help from some one to build and test latest changes on AIX, may
> be Christoph can help.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> > Vyom,
> >
> >> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> >>
> >> Hi,
> >>
> >> Please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I
> have incorporated the review comments.
> > Your changes completely avoid NET_Timeout, which is quite complex on
> > Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> > async close mechanism to signal/interrupt a thread blocked in a poll /
> > select ). Also, select is used on Mac, which will use poll after your
> > changes ( I do remember that there was a bug in poll on Mac around
> > the time of the original Mac port ).
> >
> > Would is be better, rather than replicating the logic in  NET_Timeout,
> > to have a version that supports passing a function pointer, to run if
> > the poll/select returns before the timeout? Just an idea.
> >
> > -Chris.
> >
> >> Thanks,
> >>
> >> Vyom
> >>
> >>
> >> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> >>> On 05/09/16 15:37, Mark Sheppard wrote:
> >>>> if the desire is to avoid making double calls on gettimeofday in the
> >>>> NET_ReadWithTimeout's while loop for its main call flow,
> >>> Yes, the desire is to make no more calls to gettimeofday, than are
> >>> already done.
> >>>
> >>>> then consider a modification to NET_Timeout and create a version
> >>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> >>>> current_time)
> >>>>
> >>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> >>>> current_time) {
> >>>>     int result;
> >>>>     struct timeval t;
> >>>>     long prevtime, newtime;
> >>>>     struct pollfd pfd;
> >>>>     pfd.fd = s;
> >>>>     pfd.events = POLLIN;
> >>>>
> >>>>     if (timeout > 0) {
> >>>>         prevtime = (current_time->tv_sec * 1000)  +
> >>>> current_time->tv_usec / 1000;
> >>>>     }
> >>>>
> >>>>     for(;;) {
> >>>>         result = poll(&pfd, 1, timeout);
> >>>>         if (result < 0 && errno == EINTR) {
> >>>>             if (timeout > 0) {
> >>>>                 gettimeofday(&t, NULL);
> >>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
> >>>>                 timeout -= newtime - prevtime;
> >>>>                 if (timeout <= 0)
> >>>>                     return 0;
> >>>>                 prevtime = newtime;
> >>>>             }
> >>>>         } else {
> >>>>             return result;
> >>>>         }
> >>>>     }
> >>>> }
> >>>>
> >>>> the NET_ReadWithTimeout is modified with.
> >>>>
> >>>>    while (timeout > 0) {
> >>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
> >>>>
> >>>> in any case there is the potential for multiple invocation of
> >>>> gettimeofday due to a need to make
> >>>> poll restartable,
> >>> Yes, and that is fine. Just no more than is already there.
> >>>
> >>> and adjust the originally specified timeout
> >>>> accordingly, and for the edge case
> >>>> after the non blocking read.
> >>> After an initial skim, your suggestion seems reasonable.
> >>>
> >>> -Chris.
> >>>
> >>>> regards
> >>>> Mark
> >>>>
> >>>>
> >>>>
> >>>> On 05/09/2016 12:02, Chris Hegarty wrote:
> >>>>> Vyom,
> >>>>>
> >>>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>
> >>>>> There is some concern about the potential performance effect, etc,
> >>>>> of gettimeofday, maybe there is a way out of this. The reuse of
> >>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
> >>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
> >>>>> NET_Timeout, but effectively inline its interruptible operation.
> >>>>> Or write a variant of NET_Timeout that takes a function to
> >>>>> execute. Rather than effectively two loops conditioned on the
> >>>>> timeout.  Disclaimer: I have not actually tried to do this, but
> >>>>> it seems worth considering / evaluating.
> >>>>>
> >>>>> -Chris.
> >>>>>
> >>>>> On 02/09/16 04:39, Vyom Tewari wrote:
> >>>>>> hi Dimitry,
> >>>>>>
> >>>>>> thanks for review, I did consider to use  a monotonically increasing
> >>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout")
> uses
> >>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Vyom
> >>>>>>
> >>>>>>
> >>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
> >>>>>>> Vyom,
> >>>>>>>
> >>>>>>> Did you consider to use select() to calculate timeout instead of
> >>>>>>> gettimeofday ?
> >>>>>>>
> >>>>>>> gettimeofday is affected by system time changes, so running ntpd can
> >>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
> >>>>>>> syscall.
> >>>>>>>
> >>>>>>> -Dmitry
> >>>>>>>
> >>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
> >>>>>>>> please find the updated
> >>>>>>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>
> >>>>>>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
> >>>>>>>> I
> >>>>>>>> incorporated the review comments.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Vyom
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
> >>>>>>>>> Hi
> >>>>>>>>>    perhaps there is an opportunity to do  some refactoring here (...
> >>>>>>>>> for me a "goto " carries a code smell! )
> >>>>>>>>>
> >>>>>>>>> along the lines
> >>>>>>>>>
> >>>>>>>>> if (timeout) {
> >>>>>>>>>      nread =  NET_ReadWithTimeout(...);
> >>>>>>>>> } else {
> >>>>>>>>>       nread = NET_Read(...);
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
> >>>>>>>>> restructuring of
> >>>>>>>>> your goto loop
> >>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
> >>>>>>>>>            if (nread <= 0) {
> >>>>>>>>>                if (nread == 0) {
> >>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>> "SocketTimeoutException",
> >>>>>>>>>                                "Read timed out");
> >>>>>>>>>                } else if (nread == -1) {
> >>>>>>>>>                    if (errno == EBADF) {
> >>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>> "SocketException", "Socket closed");
> >>>>>>>>>                    } else if (errno == ENOMEM) {
> >>>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
> >>>>>>>>> native heap allocation failed");
> >>>>>>>>>                    } else {
> >>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
> >>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
> >>>>>>>>> "select/poll failed");
> >>>>>>>>>                    }
> >>>>>>>>>                }
> >>>>>>>>>                  // release buffer in main call flow
> >>>>>>>>> //              if (bufP != BUF) {
> >>>>>>>>> //                  free(bufP);
> >>>>>>>>> //             }
> >>>>>>>>>               nread = -1;
> >>>>>>>>>               break;
> >>>>>>>>>            } else {
> >>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
> >>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
> EWOULDBLOCK))) {
> >>>>>>>>>                gettimeofday(&t, NULL);
> >>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> >>>>>>>>> _timeout -= newtime - prevtime;
> >>>>>>>>> if(_timeout > 0){
> >>>>>>>>> prevtime = newtime;
> >>>>>>>>>                    }
> >>>>>>>>> } else { break; } } } return nread;
> >>>>>>>>>
> >>>>>>>>> e&oe
> >>>>>>>>>
> >>>>>>>>> regards
> >>>>>>>>> Mark
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
> >>>>>>>>>> gentle reminder, please review the below code change.
> >>>>>>>>>>
> >>>>>>>>>> Vyom
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
> >>>>>>>>>>> Hi All,
> >>>>>>>>>>>
> >>>>>>>>>>> Please review the code changes for below issue.
> >>>>>>>>>>>
> >>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
> >>>>>>>>>>>
> >>>>>>>>>>> webrev    :
> >>>>>>>>>>>
> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> >>>>>>>>>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
> >>>>>>>>>>> "soTimeout" set.the implementation of
> >>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that
> read()
> >>>>>>>>>>> won't block after poll() reports that a read is possible.
> >>>>>>>>>>>
> >>>>>>>>>>> This assumption does not hold, as noted on the man page for
> select
> >>>>>>>>>>> (referenced by the man page for poll): Under Linux, select() may
> >>>>>>>>>>> report a socket file descriptor as "ready for reading", while
> >>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
> >>>>>>>>>>> happen
> >>>>>>>>>>> when data has arrived but upon examination has wrong
> checksum
> >>>>>>>>>>> and is
> >>>>>>>>>>> discarded.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Vyom
> >>>>>>>>>>>
> >>>>>>>>>>>


From chris.hegarty at oracle.com  Wed Sep  7 09:48:25 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 7 Sep 2016 10:48:25 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
Message-ID: <85583067-4549-3131-3714-9fb232ccd3de@oracle.com>



On 07/09/16 07:45, Vyom Tewari wrote:
> Hi Chris,
>
> Please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
> did some code refactoring, JPRT is in progress.

In terms of NET_Timeout**, I'm happy with this version, but I
have an additional comment.

If NET_ReadWithTimeout returns -1 because NET_TimeoutWithCurrentTime
returns <= 0, then a JNI pending exception will be set. So the code
calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
immediately rather than continuing and possibly trying to set another
JNI pending exception.

One option is to check the return value from NET_ReadWithTimeout and
also (*env)->ExceptionCheck(env). Another is to possibly consolidate the 
setting of JNI pending exceptions in one place, towards the end
of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
handled in two places.

-Chris.

> I need help from some one to build and test latest changes on AIX, may
> be Christoph can help.
>
> Thanks,
>
> Vyom
>
>
> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>> Vyom,
>>
>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Please find the latest
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I
>>> have incorporated the review comments.
>> Your changes completely avoid NET_Timeout, which is quite complex on
>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>> async close mechanism to signal/interrupt a thread blocked in a poll /
>> select ). Also, select is used on Mac, which will use poll after your
>> changes ( I do remember that there was a bug in poll on Mac around
>> the time of the original Mac port ).
>>
>> Would is be better, rather than replicating the logic in  NET_Timeout,
>> to have a version that supports passing a function pointer, to run if
>> the poll/select returns before the timeout? Just an idea.
>>
>> -Chris.
>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>> already done.
>>>>
>>>>> then consider a modification to NET_Timeout and create a version
>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>> current_time)
>>>>>
>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>> current_time) {
>>>>>     int result;
>>>>>     struct timeval t;
>>>>>     long prevtime, newtime;
>>>>>     struct pollfd pfd;
>>>>>     pfd.fd = s;
>>>>>     pfd.events = POLLIN;
>>>>>
>>>>>     if (timeout > 0) {
>>>>>         prevtime = (current_time->tv_sec * 1000)  +
>>>>> current_time->tv_usec / 1000;
>>>>>     }
>>>>>
>>>>>     for(;;) {
>>>>>         result = poll(&pfd, 1, timeout);
>>>>>         if (result < 0 && errno == EINTR) {
>>>>>             if (timeout > 0) {
>>>>>                 gettimeofday(&t, NULL);
>>>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
>>>>>                 timeout -= newtime - prevtime;
>>>>>                 if (timeout <= 0)
>>>>>                     return 0;
>>>>>                 prevtime = newtime;
>>>>>             }
>>>>>         } else {
>>>>>             return result;
>>>>>         }
>>>>>     }
>>>>> }
>>>>>
>>>>> the NET_ReadWithTimeout is modified with.
>>>>>
>>>>>    while (timeout > 0) {
>>>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>
>>>>> in any case there is the potential for multiple invocation of
>>>>> gettimeofday due to a need to make
>>>>> poll restartable,
>>>> Yes, and that is fine. Just no more than is already there.
>>>>
>>>> and adjust the originally specified timeout
>>>>> accordingly, and for the edge case
>>>>> after the non blocking read.
>>>> After an initial skim, your suggestion seems reasonable.
>>>>
>>>> -Chris.
>>>>
>>>>> regards
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>> Vyom,
>>>>>>
>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>
>>>>>>
>>>>>> There is some concern about the potential performance effect, etc,
>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>> it seems worth considering / evaluating.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>> hi Dimitry,
>>>>>>>
>>>>>>> thanks for review, I did consider to use  a monotonically increasing
>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>> code("NET_Timeout") uses
>>>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>>> Vyom,
>>>>>>>>
>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>> gettimeofday ?
>>>>>>>>
>>>>>>>> gettimeofday is affected by system time changes, so running ntpd
>>>>>>>> can
>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>> expensive
>>>>>>>> syscall.
>>>>>>>>
>>>>>>>> -Dmitry
>>>>>>>>
>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>> please find the updated
>>>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>>>
>>>>>>>>> I
>>>>>>>>> incorporated the review comments.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>> Hi
>>>>>>>>>>    perhaps there is an opportunity to do  some refactoring
>>>>>>>>>> here (...
>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>
>>>>>>>>>> along the lines
>>>>>>>>>>
>>>>>>>>>> if (timeout) {
>>>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>>>> } else {
>>>>>>>>>>       nread = NET_Read(...);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>> restructuring of
>>>>>>>>>> your goto loop
>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>            if (nread <= 0) {
>>>>>>>>>>                if (nread == 0) {
>>>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>                                "Read timed out");
>>>>>>>>>>                } else if (nread == -1) {
>>>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>>>>                        JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>> "NET_Timeout
>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>                    } else {
>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>                            (env, JNU_JAVANETPKG
>>>>>>>>>> "SocketException",
>>>>>>>>>> "select/poll failed");
>>>>>>>>>>                    }
>>>>>>>>>>                }
>>>>>>>>>>                  // release buffer in main call flow
>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>> //                  free(bufP);
>>>>>>>>>> //             }
>>>>>>>>>>               nread = -1;
>>>>>>>>>>               break;
>>>>>>>>>>            } else {
>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>                    }
>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>
>>>>>>>>>> e&oe
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>
>>>>>>>>>>> Vyom
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>
>>>>>>>>>>>> webrev    :
>>>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>>>
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that read()
>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>
>>>>>>>>>>>> This assumption does not hold, as noted on the man page for
>>>>>>>>>>>> select
>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
>>>>>>>>>>>> may
>>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>>>> happen
>>>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>>>> and is
>>>>>>>>>>>> discarded.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Vyom
>>>>>>>>>>>>
>>>>>>>>>>>>
>

From christoph.langer at sap.com  Wed Sep  7 10:57:51 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 7 Sep 2016 10:57:51 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com> 
Message-ID: <6f2336b5d4ed48518f983a42dbd3c7d4@DEWDFE13DE11.global.corp.sap>

Hi Vyom,

I ran an AIX build and I had to change the flag for the recv call in NET_NonBlockingRead from MSG_DONTWAIT to MSG_NONBLOCK to get it compiled. Other than that it's fine in principal.

However, I had another look about where to place which code. I suggest to put the common NET_* functions which don't have specific implementations on the various operating systems in file net_util_md.c. That way we'll avoid some code deduplication and code is located at more logical places, at least from my perspective.

Please check my webrev which is an update to your latest suggestion:
http://cr.openjdk.java.net/~clanger/webrevs/8075484-clanger/

Maybe that's a better distribution of code?

It builds on AIX - other platforms I didn't test so far.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 7. September 2016 11:20
> To: 'Vyom Tewari' <vyom.tewari at oracle.com>
> Cc: net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
> Subject: RE: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Hi Vyom,
> 
> I'll do an AIX build with your patch and let you know later today.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
> Vyom
> > Tewari
> > Sent: Mittwoch, 7. September 2016 08:46
> > To: Chris Hegarty <chris.hegarty at oracle.com>
> > Cc: net-dev at openjdk.java.net
> > Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> > soTimeout set
> >
> > Hi Chris,
> >
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> > <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
> > did some code refactoring, JPRT is in progress.
> >
> > I need help from some one to build and test latest changes on AIX, may
> > be Christoph can help.
> >
> > Thanks,
> >
> > Vyom
> >
> >
> > On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> > > Vyom,
> > >
> > >> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> > <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). I
> > have incorporated the review comments.
> > > Your changes completely avoid NET_Timeout, which is quite complex on
> > > Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> > > async close mechanism to signal/interrupt a thread blocked in a poll /
> > > select ). Also, select is used on Mac, which will use poll after your
> > > changes ( I do remember that there was a bug in poll on Mac around
> > > the time of the original Mac port ).
> > >
> > > Would is be better, rather than replicating the logic in  NET_Timeout,
> > > to have a version that supports passing a function pointer, to run if
> > > the poll/select returns before the timeout? Just an idea.
> > >
> > > -Chris.
> > >
> > >> Thanks,
> > >>
> > >> Vyom
> > >>
> > >>
> > >> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> > >>> On 05/09/16 15:37, Mark Sheppard wrote:
> > >>>> if the desire is to avoid making double calls on gettimeofday in the
> > >>>> NET_ReadWithTimeout's while loop for its main call flow,
> > >>> Yes, the desire is to make no more calls to gettimeofday, than are
> > >>> already done.
> > >>>
> > >>>> then consider a modification to NET_Timeout and create a version
> > >>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> > >>>> current_time)
> > >>>>
> > >>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> > >>>> current_time) {
> > >>>>     int result;
> > >>>>     struct timeval t;
> > >>>>     long prevtime, newtime;
> > >>>>     struct pollfd pfd;
> > >>>>     pfd.fd = s;
> > >>>>     pfd.events = POLLIN;
> > >>>>
> > >>>>     if (timeout > 0) {
> > >>>>         prevtime = (current_time->tv_sec * 1000)  +
> > >>>> current_time->tv_usec / 1000;
> > >>>>     }
> > >>>>
> > >>>>     for(;;) {
> > >>>>         result = poll(&pfd, 1, timeout);
> > >>>>         if (result < 0 && errno == EINTR) {
> > >>>>             if (timeout > 0) {
> > >>>>                 gettimeofday(&t, NULL);
> > >>>>                 newtime = (t.tv_sec * 1000)  +  t.tv_usec /1000;
> > >>>>                 timeout -= newtime - prevtime;
> > >>>>                 if (timeout <= 0)
> > >>>>                     return 0;
> > >>>>                 prevtime = newtime;
> > >>>>             }
> > >>>>         } else {
> > >>>>             return result;
> > >>>>         }
> > >>>>     }
> > >>>> }
> > >>>>
> > >>>> the NET_ReadWithTimeout is modified with.
> > >>>>
> > >>>>    while (timeout > 0) {
> > >>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
> > >>>>
> > >>>> in any case there is the potential for multiple invocation of
> > >>>> gettimeofday due to a need to make
> > >>>> poll restartable,
> > >>> Yes, and that is fine. Just no more than is already there.
> > >>>
> > >>> and adjust the originally specified timeout
> > >>>> accordingly, and for the edge case
> > >>>> after the non blocking read.
> > >>> After an initial skim, your suggestion seems reasonable.
> > >>>
> > >>> -Chris.
> > >>>
> > >>>> regards
> > >>>> Mark
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 05/09/2016 12:02, Chris Hegarty wrote:
> > >>>>> Vyom,
> > >>>>>
> > >>>>>
> > webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> > >>>>>
> > >>>>> There is some concern about the potential performance effect, etc,
> > >>>>> of gettimeofday, maybe there is a way out of this. The reuse of
> > >>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
> > >>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
> > >>>>> NET_Timeout, but effectively inline its interruptible operation.
> > >>>>> Or write a variant of NET_Timeout that takes a function to
> > >>>>> execute. Rather than effectively two loops conditioned on the
> > >>>>> timeout.  Disclaimer: I have not actually tried to do this, but
> > >>>>> it seems worth considering / evaluating.
> > >>>>>
> > >>>>> -Chris.
> > >>>>>
> > >>>>> On 02/09/16 04:39, Vyom Tewari wrote:
> > >>>>>> hi Dimitry,
> > >>>>>>
> > >>>>>> thanks for review, I did consider to use  a monotonically increasing
> > >>>>>> clock like "clock_gettime" but  existing nearby code("NET_Timeout")
> > uses
> > >>>>>> "gettimeofday"  so i choose to be consistent with the existing code.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>
> > >>>>>> Vyom
> > >>>>>>
> > >>>>>>
> > >>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
> > >>>>>>> Vyom,
> > >>>>>>>
> > >>>>>>> Did you consider to use select() to calculate timeout instead of
> > >>>>>>> gettimeofday ?
> > >>>>>>>
> > >>>>>>> gettimeofday is affected by system time changes, so running ntpd
> can
> > >>>>>>> cause unpredictable behavior of this code. Also it's rather expensive
> > >>>>>>> syscall.
> > >>>>>>>
> > >>>>>>> -Dmitry
> > >>>>>>>
> > >>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
> > >>>>>>>> please find the updated
> > >>>>>>>>
> > webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> > >>>>>>>>
> > >>>>>>>>
> > <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
> > >>>>>>>> I
> > >>>>>>>> incorporated the review comments.
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>>
> > >>>>>>>> Vyom
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
> > >>>>>>>>> Hi
> > >>>>>>>>>    perhaps there is an opportunity to do  some refactoring here (...
> > >>>>>>>>> for me a "goto " carries a code smell! )
> > >>>>>>>>>
> > >>>>>>>>> along the lines
> > >>>>>>>>>
> > >>>>>>>>> if (timeout) {
> > >>>>>>>>>      nread =  NET_ReadWithTimeout(...);
> > >>>>>>>>> } else {
> > >>>>>>>>>       nread = NET_Read(...);
> > >>>>>>>>> }
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
> > >>>>>>>>> restructuring of
> > >>>>>>>>> your goto loop
> > >>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
> > >>>>>>>>>            if (nread <= 0) {
> > >>>>>>>>>                if (nread == 0) {
> > >>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
> > >>>>>>>>> "SocketTimeoutException",
> > >>>>>>>>>                                "Read timed out");
> > >>>>>>>>>                } else if (nread == -1) {
> > >>>>>>>>>                    if (errno == EBADF) {
> > >>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
> > >>>>>>>>> "SocketException", "Socket closed");
> > >>>>>>>>>                    } else if (errno == ENOMEM) {
> > >>>>>>>>>                        JNU_ThrowOutOfMemoryError(env, "NET_Timeout
> > >>>>>>>>> native heap allocation failed");
> > >>>>>>>>>                    } else {
> > >>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
> > >>>>>>>>>                            (env, JNU_JAVANETPKG "SocketException",
> > >>>>>>>>> "select/poll failed");
> > >>>>>>>>>                    }
> > >>>>>>>>>                }
> > >>>>>>>>>                  // release buffer in main call flow
> > >>>>>>>>> //              if (bufP != BUF) {
> > >>>>>>>>> //                  free(bufP);
> > >>>>>>>>> //             }
> > >>>>>>>>>               nread = -1;
> > >>>>>>>>>               break;
> > >>>>>>>>>            } else {
> > >>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
> > >>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
> > EWOULDBLOCK))) {
> > >>>>>>>>>                gettimeofday(&t, NULL);
> > >>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> > >>>>>>>>> _timeout -= newtime - prevtime;
> > >>>>>>>>> if(_timeout > 0){
> > >>>>>>>>> prevtime = newtime;
> > >>>>>>>>>                    }
> > >>>>>>>>> } else { break; } } } return nread;
> > >>>>>>>>>
> > >>>>>>>>> e&oe
> > >>>>>>>>>
> > >>>>>>>>> regards
> > >>>>>>>>> Mark
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
> > >>>>>>>>>> gentle reminder, please review the below code change.
> > >>>>>>>>>>
> > >>>>>>>>>> Vyom
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
> > >>>>>>>>>>> Hi All,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Please review the code changes for below issue.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
> > >>>>>>>>>>>
> > >>>>>>>>>>> webrev    :
> > >>>>>>>>>>>
> > http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> > >>>>>>>>>>>
> > <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
> > >>>>>>>>>>> "soTimeout" set.the implementation of
> > >>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that
> > read()
> > >>>>>>>>>>> won't block after poll() reports that a read is possible.
> > >>>>>>>>>>>
> > >>>>>>>>>>> This assumption does not hold, as noted on the man page for
> > select
> > >>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
> may
> > >>>>>>>>>>> report a socket file descriptor as "ready for reading", while
> > >>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
> > >>>>>>>>>>> happen
> > >>>>>>>>>>> when data has arrived but upon examination has wrong
> > checksum
> > >>>>>>>>>>> and is
> > >>>>>>>>>>> discarded.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Vyom
> > >>>>>>>>>>>
> > >>>>>>>>>>>


From rob.mckenna at oracle.com  Wed Sep  7 13:17:19 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 7 Sep 2016 14:17:19 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
Message-ID: <20160907131719.GA5531@vimes>

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. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.

In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.

	-Rob

From vyom.tewari at oracle.com  Wed Sep  7 15:09:41 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 7 Sep 2016 20:39:41 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
Message-ID: <c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>

Hi All,

Please find the latest 
webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>). 
there were some test failures in JPRT and Chris also pointed the same 
issue in modified code. Now with latest code JPRT is clean.

Thanks,

Vyom


On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>
>
> On 07/09/16 07:45, Vyom Tewari wrote:
>> Hi Chris,
>>
>> Please find the latest
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
>> did some code refactoring, JPRT is in progress.
>
> In terms of NET_Timeout**, I'm happy with this version, but I
> have an additional comment.
>
> If NET_ReadWithTimeout returns -1 because NET_TimeoutWithCurrentTime
> returns <= 0, then a JNI pending exception will be set. So the code
> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
> immediately rather than continuing and possibly trying to set another
> JNI pending exception.
>
> One option is to check the return value from NET_ReadWithTimeout and
> also (*env)->ExceptionCheck(env). Another is to possibly consolidate 
> the setting of JNI pending exceptions in one place, towards the end
> of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
> handled in two places.
>
> -Chris.
>
>> I need help from some one to build and test latest changes on AIX, may
>> be Christoph can help.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>> Vyom,
>>>
>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please find the latest
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html 
>>>>
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). 
>>>> I
>>>> have incorporated the review comments.
>>> Your changes completely avoid NET_Timeout, which is quite complex on
>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>> select ). Also, select is used on Mac, which will use poll after your
>>> changes ( I do remember that there was a bug in poll on Mac around
>>> the time of the original Mac port ).
>>>
>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>> to have a version that supports passing a function pointer, to run if
>>> the poll/select returns before the timeout? Just an idea.
>>>
>>> -Chris.
>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>> already done.
>>>>>
>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>>> current_time)
>>>>>>
>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>>> current_time) {
>>>>>>     int result;
>>>>>>     struct timeval t;
>>>>>>     long prevtime, newtime;
>>>>>>     struct pollfd pfd;
>>>>>>     pfd.fd = s;
>>>>>>     pfd.events = POLLIN;
>>>>>>
>>>>>>     if (timeout > 0) {
>>>>>>         prevtime = (current_time->tv_sec * 1000)  +
>>>>>> current_time->tv_usec / 1000;
>>>>>>     }
>>>>>>
>>>>>>     for(;;) {
>>>>>>         result = poll(&pfd, 1, timeout);
>>>>>>         if (result < 0 && errno == EINTR) {
>>>>>>             if (timeout > 0) {
>>>>>>                 gettimeofday(&t, NULL);
>>>>>>                 newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>                 timeout -= newtime - prevtime;
>>>>>>                 if (timeout <= 0)
>>>>>>                     return 0;
>>>>>>                 prevtime = newtime;
>>>>>>             }
>>>>>>         } else {
>>>>>>             return result;
>>>>>>         }
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>
>>>>>>    while (timeout > 0) {
>>>>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>
>>>>>> in any case there is the potential for multiple invocation of
>>>>>> gettimeofday due to a need to make
>>>>>> poll restartable,
>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>
>>>>> and adjust the originally specified timeout
>>>>>> accordingly, and for the edge case
>>>>>> after the non blocking read.
>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> regards
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>> Vyom,
>>>>>>>
>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There is some concern about the potential performance effect, etc,
>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>> it seems worth considering / evaluating.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>> hi Dimitry,
>>>>>>>>
>>>>>>>> thanks for review, I did consider to use  a monotonically 
>>>>>>>> increasing
>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>> code("NET_Timeout") uses
>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing 
>>>>>>>> code.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>>>> Vyom,
>>>>>>>>>
>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>> gettimeofday ?
>>>>>>>>>
>>>>>>>>> gettimeofday is affected by system time changes, so running ntpd
>>>>>>>>> can
>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>> expensive
>>>>>>>>> syscall.
>>>>>>>>>
>>>>>>>>> -Dmitry
>>>>>>>>>
>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>> please find the updated
>>>>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I
>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>> Hi
>>>>>>>>>>>    perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>> here (...
>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>
>>>>>>>>>>> along the lines
>>>>>>>>>>>
>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>      nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>> } else {
>>>>>>>>>>>       nread = NET_Read(...);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>> restructuring of
>>>>>>>>>>> your goto loop
>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>            if (nread <= 0) {
>>>>>>>>>>>                if (nread == 0) {
>>>>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>                                "Read timed out");
>>>>>>>>>>>                } else if (nread == -1) {
>>>>>>>>>>>                    if (errno == EBADF) {
>>>>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>                    } else if (errno == ENOMEM) {
>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>                    } else {
>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>                            (env, JNU_JAVANETPKG
>>>>>>>>>>> "SocketException",
>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>                    }
>>>>>>>>>>>                }
>>>>>>>>>>>                  // release buffer in main call flow
>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>> //             }
>>>>>>>>>>>               nread = -1;
>>>>>>>>>>>               break;
>>>>>>>>>>>            } else {
>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>                gettimeofday(&t, NULL);
>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>                    }
>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>
>>>>>>>>>>> e&oe
>>>>>>>>>>>
>>>>>>>>>>> regards
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>
>>>>>>>>>>>> Vyom
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug         : 
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>
>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html 
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html> 
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that 
>>>>>>>>>>>>> read()
>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This assumption does not hold, as noted on the man page for
>>>>>>>>>>>>> select
>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
>>>>>>>>>>>>> may
>>>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>>>>> happen
>>>>>>>>>>>>> when data has arrived but upon examination has wrong checksum
>>>>>>>>>>>>> and is
>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>


From christoph.langer at sap.com  Wed Sep  7 15:14:20 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 7 Sep 2016 15:14:20 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
Message-ID: <2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>

Hi Vyom,

did you have a look at my suggestions regarding AIX and refactoring? I can't find none of it in the new webrev nor did you comment on it.

Best regards
Christoph

> -----Original Message-----
> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Vyom
> Tewari
> Sent: Mittwoch, 7. September 2016 17:10
> To: Chris Hegarty <chris.hegarty at oracle.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Hi All,
> 
> Please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
> there were some test failures in JPRT and Chris also pointed the same
> issue in modified code. Now with latest code JPRT is clean.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
> >
> >
> > On 07/09/16 07:45, Vyom Tewari wrote:
> >> Hi Chris,
> >>
> >> Please find the latest
> >> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> >> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
> >> did some code refactoring, JPRT is in progress.
> >
> > In terms of NET_Timeout**, I'm happy with this version, but I
> > have an additional comment.
> >
> > If NET_ReadWithTimeout returns -1 because NET_TimeoutWithCurrentTime
> > returns <= 0, then a JNI pending exception will be set. So the code
> > calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
> > immediately rather than continuing and possibly trying to set another
> > JNI pending exception.
> >
> > One option is to check the return value from NET_ReadWithTimeout and
> > also (*env)->ExceptionCheck(env). Another is to possibly consolidate
> > the setting of JNI pending exceptions in one place, towards the end
> > of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
> > handled in two places.
> >
> > -Chris.
> >
> >> I need help from some one to build and test latest changes on AIX, may
> >> be Christoph can help.
> >>
> >> Thanks,
> >>
> >> Vyom
> >>
> >>
> >> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> >>> Vyom,
> >>>
> >>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Please find the latest
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> >>>>
> >>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
> >>>> I
> >>>> have incorporated the review comments.
> >>> Your changes completely avoid NET_Timeout, which is quite complex on
> >>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> >>> async close mechanism to signal/interrupt a thread blocked in a poll /
> >>> select ). Also, select is used on Mac, which will use poll after your
> >>> changes ( I do remember that there was a bug in poll on Mac around
> >>> the time of the original Mac port ).
> >>>
> >>> Would is be better, rather than replicating the logic in NET_Timeout,
> >>> to have a version that supports passing a function pointer, to run if
> >>> the poll/select returns before the timeout? Just an idea.
> >>>
> >>> -Chris.
> >>>
> >>>> Thanks,
> >>>>
> >>>> Vyom
> >>>>
> >>>>
> >>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> >>>>> On 05/09/16 15:37, Mark Sheppard wrote:
> >>>>>> if the desire is to avoid making double calls on gettimeofday in the
> >>>>>> NET_ReadWithTimeout's while loop for its main call flow,
> >>>>> Yes, the desire is to make no more calls to gettimeofday, than are
> >>>>> already done.
> >>>>>
> >>>>>> then consider a modification to NET_Timeout and create a version
> >>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> >>>>>> current_time)
> >>>>>>
> >>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> >>>>>> current_time) {
> >>>>>>     int result;
> >>>>>>     struct timeval t;
> >>>>>>     long prevtime, newtime;
> >>>>>>     struct pollfd pfd;
> >>>>>>     pfd.fd = s;
> >>>>>>     pfd.events = POLLIN;
> >>>>>>
> >>>>>>     if (timeout > 0) {
> >>>>>>         prevtime = (current_time->tv_sec * 1000)  +
> >>>>>> current_time->tv_usec / 1000;
> >>>>>>     }
> >>>>>>
> >>>>>>     for(;;) {
> >>>>>>         result = poll(&pfd, 1, timeout);
> >>>>>>         if (result < 0 && errno == EINTR) {
> >>>>>>             if (timeout > 0) {
> >>>>>>                 gettimeofday(&t, NULL);
> >>>>>>                 newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
> >>>>>>                 timeout -= newtime - prevtime;
> >>>>>>                 if (timeout <= 0)
> >>>>>>                     return 0;
> >>>>>>                 prevtime = newtime;
> >>>>>>             }
> >>>>>>         } else {
> >>>>>>             return result;
> >>>>>>         }
> >>>>>>     }
> >>>>>> }
> >>>>>>
> >>>>>> the NET_ReadWithTimeout is modified with.
> >>>>>>
> >>>>>>    while (timeout > 0) {
> >>>>>>         result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
> >>>>>>
> >>>>>> in any case there is the potential for multiple invocation of
> >>>>>> gettimeofday due to a need to make
> >>>>>> poll restartable,
> >>>>> Yes, and that is fine. Just no more than is already there.
> >>>>>
> >>>>> and adjust the originally specified timeout
> >>>>>> accordingly, and for the edge case
> >>>>>> after the non blocking read.
> >>>>> After an initial skim, your suggestion seems reasonable.
> >>>>>
> >>>>> -Chris.
> >>>>>
> >>>>>> regards
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
> >>>>>>> Vyom,
> >>>>>>>
> >>>>>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> There is some concern about the potential performance effect, etc,
> >>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
> >>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
> >>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
> >>>>>>> NET_Timeout, but effectively inline its interruptible operation.
> >>>>>>> Or write a variant of NET_Timeout that takes a function to
> >>>>>>> execute. Rather than effectively two loops conditioned on the
> >>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
> >>>>>>> it seems worth considering / evaluating.
> >>>>>>>
> >>>>>>> -Chris.
> >>>>>>>
> >>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
> >>>>>>>> hi Dimitry,
> >>>>>>>>
> >>>>>>>> thanks for review, I did consider to use  a monotonically
> >>>>>>>> increasing
> >>>>>>>> clock like "clock_gettime" but  existing nearby
> >>>>>>>> code("NET_Timeout") uses
> >>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
> >>>>>>>> code.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Vyom
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
> >>>>>>>>> Vyom,
> >>>>>>>>>
> >>>>>>>>> Did you consider to use select() to calculate timeout instead of
> >>>>>>>>> gettimeofday ?
> >>>>>>>>>
> >>>>>>>>> gettimeofday is affected by system time changes, so running ntpd
> >>>>>>>>> can
> >>>>>>>>> cause unpredictable behavior of this code. Also it's rather
> >>>>>>>>> expensive
> >>>>>>>>> syscall.
> >>>>>>>>>
> >>>>>>>>> -Dmitry
> >>>>>>>>>
> >>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
> >>>>>>>>>> please find the updated
> >>>>>>>>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I
> >>>>>>>>>> incorporated the review comments.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Vyom
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
> >>>>>>>>>>> Hi
> >>>>>>>>>>>    perhaps there is an opportunity to do  some refactoring
> >>>>>>>>>>> here (...
> >>>>>>>>>>> for me a "goto " carries a code smell! )
> >>>>>>>>>>>
> >>>>>>>>>>> along the lines
> >>>>>>>>>>>
> >>>>>>>>>>> if (timeout) {
> >>>>>>>>>>>      nread =  NET_ReadWithTimeout(...);
> >>>>>>>>>>> } else {
> >>>>>>>>>>>       nread = NET_Read(...);
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
> >>>>>>>>>>> restructuring of
> >>>>>>>>>>> your goto loop
> >>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
> >>>>>>>>>>>            if (nread <= 0) {
> >>>>>>>>>>>                if (nread == 0) {
> >>>>>>>>>>>                    JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>>>> "SocketTimeoutException",
> >>>>>>>>>>>                                "Read timed out");
> >>>>>>>>>>>                } else if (nread == -1) {
> >>>>>>>>>>>                    if (errno == EBADF) {
> >>>>>>>>>>>                         JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>>>> "SocketException", "Socket closed");
> >>>>>>>>>>>                    } else if (errno == ENOMEM) {
> >>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
> >>>>>>>>>>> "NET_Timeout
> >>>>>>>>>>> native heap allocation failed");
> >>>>>>>>>>>                    } else {
> >>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
> >>>>>>>>>>>                            (env, JNU_JAVANETPKG
> >>>>>>>>>>> "SocketException",
> >>>>>>>>>>> "select/poll failed");
> >>>>>>>>>>>                    }
> >>>>>>>>>>>                }
> >>>>>>>>>>>                  // release buffer in main call flow
> >>>>>>>>>>> //              if (bufP != BUF) {
> >>>>>>>>>>> //                  free(bufP);
> >>>>>>>>>>> //             }
> >>>>>>>>>>>               nread = -1;
> >>>>>>>>>>>               break;
> >>>>>>>>>>>            } else {
> >>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
> >>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
> >>>>>>>>>>> EWOULDBLOCK))) {
> >>>>>>>>>>>                gettimeofday(&t, NULL);
> >>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> >>>>>>>>>>> _timeout -= newtime - prevtime;
> >>>>>>>>>>> if(_timeout > 0){
> >>>>>>>>>>> prevtime = newtime;
> >>>>>>>>>>>                    }
> >>>>>>>>>>> } else { break; } } } return nread;
> >>>>>>>>>>>
> >>>>>>>>>>> e&oe
> >>>>>>>>>>>
> >>>>>>>>>>> regards
> >>>>>>>>>>> Mark
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
> >>>>>>>>>>>> gentle reminder, please review the below code change.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Vyom
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
> >>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please review the code changes for below issue.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Bug         :
> >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> webrev    :
> >>>>>>>>>>>>>
> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
> >>>>>>>>>>>>> "soTimeout" set.the implementation of
> >>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that
> >>>>>>>>>>>>> read()
> >>>>>>>>>>>>> won't block after poll() reports that a read is possible.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This assumption does not hold, as noted on the man page for
> >>>>>>>>>>>>> select
> >>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
> >>>>>>>>>>>>> may
> >>>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
> >>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
> >>>>>>>>>>>>> happen
> >>>>>>>>>>>>> when data has arrived but upon examination has wrong
> checksum
> >>>>>>>>>>>>> and is
> >>>>>>>>>>>>> discarded.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>


From vyom.tewari at oracle.com  Wed Sep  7 16:31:10 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 7 Sep 2016 22:01:10 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
Message-ID: <008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>

Hi Chris,

Sorry I was mostly focusing on our test  failure first, i will check 
your suggestions.

Thanks,

Vyom


On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
> Hi Vyom,
>
> did you have a look at my suggestions regarding AIX and refactoring? I can't find none of it in the new webrev nor did you comment on it.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Vyom
>> Tewari
>> Sent: Mittwoch, 7. September 2016 17:10
>> To: Chris Hegarty <chris.hegarty at oracle.com>
>> Cc: net-dev at openjdk.java.net
>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
>> soTimeout set
>>
>> Hi All,
>>
>> Please find the latest
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
>> there were some test failures in JPRT and Chris also pointed the same
>> issue in modified code. Now with latest code JPRT is clean.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>
>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>> Hi Chris,
>>>>
>>>> Please find the latest
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
>>>> did some code refactoring, JPRT is in progress.
>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>> have an additional comment.
>>>
>>> If NET_ReadWithTimeout returns -1 because NET_TimeoutWithCurrentTime
>>> returns <= 0, then a JNI pending exception will be set. So the code
>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>> immediately rather than continuing and possibly trying to set another
>>> JNI pending exception.
>>>
>>> One option is to check the return value from NET_ReadWithTimeout and
>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>> the setting of JNI pending exceptions in one place, towards the end
>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
>>> handled in two places.
>>>
>>> -Chris.
>>>
>>>> I need help from some one to build and test latest changes on AIX, may
>>>> be Christoph can help.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>> Vyom,
>>>>>
>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find the latest
>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>>>>>>
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
>>>>>> I
>>>>>> have incorporated the review comments.
>>>>> Your changes completely avoid NET_Timeout, which is quite complex on
>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>>>> select ). Also, select is used on Mac, which will use poll after your
>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>> the time of the original Mac port ).
>>>>>
>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>>>> to have a version that supports passing a function pointer, to run if
>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>>>> already done.
>>>>>>>
>>>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>>>>> current_time)
>>>>>>>>
>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>>>>> current_time) {
>>>>>>>>      int result;
>>>>>>>>      struct timeval t;
>>>>>>>>      long prevtime, newtime;
>>>>>>>>      struct pollfd pfd;
>>>>>>>>      pfd.fd = s;
>>>>>>>>      pfd.events = POLLIN;
>>>>>>>>
>>>>>>>>      if (timeout > 0) {
>>>>>>>>          prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      for(;;) {
>>>>>>>>          result = poll(&pfd, 1, timeout);
>>>>>>>>          if (result < 0 && errno == EINTR) {
>>>>>>>>              if (timeout > 0) {
>>>>>>>>                  gettimeofday(&t, NULL);
>>>>>>>>                  newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>>>                  timeout -= newtime - prevtime;
>>>>>>>>                  if (timeout <= 0)
>>>>>>>>                      return 0;
>>>>>>>>                  prevtime = newtime;
>>>>>>>>              }
>>>>>>>>          } else {
>>>>>>>>              return result;
>>>>>>>>          }
>>>>>>>>      }
>>>>>>>> }
>>>>>>>>
>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>
>>>>>>>>     while (timeout > 0) {
>>>>>>>>          result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>
>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>> gettimeofday due to a need to make
>>>>>>>> poll restartable,
>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>
>>>>>>> and adjust the originally specified timeout
>>>>>>>> accordingly, and for the edge case
>>>>>>>> after the non blocking read.
>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>>> regards
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>> Vyom,
>>>>>>>>>
>>>>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There is some concern about the potential performance effect, etc,
>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>
>>>>>>>>> -Chris.
>>>>>>>>>
>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>> hi Dimitry,
>>>>>>>>>>
>>>>>>>>>> thanks for review, I did consider to use  a monotonically
>>>>>>>>>> increasing
>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>>>>>> Vyom,
>>>>>>>>>>>
>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>
>>>>>>>>>>> gettimeofday is affected by system time changes, so running ntpd
>>>>>>>>>>> can
>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>> expensive
>>>>>>>>>>> syscall.
>>>>>>>>>>>
>>>>>>>>>>> -Dmitry
>>>>>>>>>>>
>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Vyom
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>     perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>>>> here (...
>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>
>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>       nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>        nread = NET_Read(...);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>             if (nread <= 0) {
>>>>>>>>>>>>>                 if (nread == 0) {
>>>>>>>>>>>>>                     JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>                                 "Read timed out");
>>>>>>>>>>>>>                 } else if (nread == -1) {
>>>>>>>>>>>>>                     if (errno == EBADF) {
>>>>>>>>>>>>>                          JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>                     } else if (errno == ENOMEM) {
>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>                     } else {
>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>                             (env, JNU_JAVANETPKG
>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>                     }
>>>>>>>>>>>>>                 }
>>>>>>>>>>>>>                   // release buffer in main call flow
>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>                nread = -1;
>>>>>>>>>>>>>                break;
>>>>>>>>>>>>>             } else {
>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>                 gettimeofday(&t, NULL);
>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>                     }
>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>
>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards
>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>
>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even with
>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes that
>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page for
>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for example
>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>> checksum
>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>


From michael.x.mcmahon at oracle.com  Wed Sep  7 17:15:51 2016
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 07 Sep 2016 18:15:51 +0100
Subject: HTTP client API
In-Reply-To: <CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
Message-ID: <57D04B47.1030805@oracle.com>

Hi Wenbo,

First, sorry for the delay in replying. We took your comments and 
prototyped how the major ones
might be accommodated. In particular, we did the following:

- moved "business logic" out of HttpRequest. The methods for sending 
requests now
    exist in HttpClient. Given that requests are no longer associated 
with a client and can
    be sent through any client, this means that some properties of a 
request that used
    to be inherited from the client can no longer be visible in the 
HttpRequest object,
    but that is not a problem as far as I can see. This changes the look 
of the sample code
    in HttpRequest, but doesn't make it any harder to read.

- changed some method names as suggested eg newBuilder()

- added protected constructors to the public classes. This allows 
alternative implementations
    for use in mocking/test frameworks etc.

- changed the PUT, POST, GET methods in the request builder to only set 
the method type.
    PUT, POST takes the request body processor as parameter. A new 
build() method returns
    the HttpRequest.

- added a method to HttpResponse which returns the "final" request that 
was sent on the wire
    for the particular response, which might be different from the user 
initiated request.

I put an updated apidoc [1] and specdiff [2] up to show the changes. In 
particular, the sample
code described in the HttpClient docs is updated to reflect the changes.

Thanks,
Michael

[1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/

[2] 
http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html

On 26/08/2016, 07:59, Wenbo Zhu wrote:
> Hi Michael,
>
> Thanks for the update! The adoption of the Flow API is indeed a big 
> improvement (async flow-control is very hard to get right).
>
> Attached is a feedback doc on this new version. One specific idea to 
> discuss is whether it's possible to release the new HTTP client API as 
> a standalone library (that works on JDK 9).
>
> Thanks,
> Wenbo
>
>
>
> On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon 
> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at 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.
>
>     Thanks,
>
>     Michael
>
>     [1] http://cr.openjdk.java.net/~michaelm/httpclient/api/
>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/api/>
>
>     [2]
>     http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout/package-summary.html
>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/specdiffout/package-summary.html>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160907/4ac1fcd7/attachment.html>

From artem.smotrakov at oracle.com  Wed Sep  7 22:17:17 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 7 Sep 2016 15:17:17 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
Message-ID: <6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>

Sending to net-dev at openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
> Hello,
>
> Please review the following patch for 
> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>
> The test has been observed to fail a couple of times, but it's still 
> not clear why it failed because there is not much info in logs. The 
> patch updates the test to enable additional debug output, so that we 
> have more info if it fails next time.
>
> While looking at the test, I notices a couple of issues, but they 
> don't seem to cause these intermittent failures:
> - The test sets system properties for JSSE in a loop, but JSSE 
> provider reads them only once while initialization. As a result, only 
> values which were set in the first iteration are actually used.
> - The test doesn't close files and sockets sometimes.
>
> The patch also fixed the issues above, and there are a couple cosmetic 
> changes.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>
> Artem


From christoph.langer at sap.com  Thu Sep  8 07:02:59 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 8 Sep 2016 07:02:59 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
Message-ID: <be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>

Hi Vyom,

ok, thanks. I have one addition to my proposal: I don't think there's a need for a global NET_GetCurrentTime function. This one should probably be a static function inside net_util_md.c (static long getCurrentTime()).

Best
Christoph

> -----Original Message-----
> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
> Sent: Mittwoch, 7. September 2016 18:31
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Hi Chris,
> 
> Sorry I was mostly focusing on our test  failure first, i will check
> your suggestions.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
> > Hi Vyom,
> >
> > did you have a look at my suggestions regarding AIX and refactoring? I can't
> find none of it in the new webrev nor did you comment on it.
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
> Vyom
> >> Tewari
> >> Sent: Mittwoch, 7. September 2016 17:10
> >> To: Chris Hegarty <chris.hegarty at oracle.com>
> >> Cc: net-dev at openjdk.java.net
> >> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
> with
> >> soTimeout set
> >>
> >> Hi All,
> >>
> >> Please find the latest
> >> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
> >> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
> >> there were some test failures in JPRT and Chris also pointed the same
> >> issue in modified code. Now with latest code JPRT is clean.
> >>
> >> Thanks,
> >>
> >> Vyom
> >>
> >>
> >> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
> >>>
> >>> On 07/09/16 07:45, Vyom Tewari wrote:
> >>>> Hi Chris,
> >>>>
> >>>> Please find the latest
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> >>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
> >>>> did some code refactoring, JPRT is in progress.
> >>> In terms of NET_Timeout**, I'm happy with this version, but I
> >>> have an additional comment.
> >>>
> >>> If NET_ReadWithTimeout returns -1 because
> NET_TimeoutWithCurrentTime
> >>> returns <= 0, then a JNI pending exception will be set. So the code
> >>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
> >>> immediately rather than continuing and possibly trying to set another
> >>> JNI pending exception.
> >>>
> >>> One option is to check the return value from NET_ReadWithTimeout and
> >>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
> >>> the setting of JNI pending exceptions in one place, towards the end
> >>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
> >>> handled in two places.
> >>>
> >>> -Chris.
> >>>
> >>>> I need help from some one to build and test latest changes on AIX, may
> >>>> be Christoph can help.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Vyom
> >>>>
> >>>>
> >>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> >>>>> Vyom,
> >>>>>
> >>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Please find the latest
> >>>>>>
> >> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> >>>>>>
> >> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
> >>>>>> I
> >>>>>> have incorporated the review comments.
> >>>>> Your changes completely avoid NET_Timeout, which is quite complex on
> >>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> >>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
> >>>>> select ). Also, select is used on Mac, which will use poll after your
> >>>>> changes ( I do remember that there was a bug in poll on Mac around
> >>>>> the time of the original Mac port ).
> >>>>>
> >>>>> Would is be better, rather than replicating the logic in NET_Timeout,
> >>>>> to have a version that supports passing a function pointer, to run if
> >>>>> the poll/select returns before the timeout? Just an idea.
> >>>>>
> >>>>> -Chris.
> >>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Vyom
> >>>>>>
> >>>>>>
> >>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> >>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
> >>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
> >>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
> >>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
> >>>>>>> already done.
> >>>>>>>
> >>>>>>>> then consider a modification to NET_Timeout and create a version
> >>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> >>>>>>>> current_time)
> >>>>>>>>
> >>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
> >>>>>>>> current_time) {
> >>>>>>>>      int result;
> >>>>>>>>      struct timeval t;
> >>>>>>>>      long prevtime, newtime;
> >>>>>>>>      struct pollfd pfd;
> >>>>>>>>      pfd.fd = s;
> >>>>>>>>      pfd.events = POLLIN;
> >>>>>>>>
> >>>>>>>>      if (timeout > 0) {
> >>>>>>>>          prevtime = (current_time->tv_sec * 1000)  +
> >>>>>>>> current_time->tv_usec / 1000;
> >>>>>>>>      }
> >>>>>>>>
> >>>>>>>>      for(;;) {
> >>>>>>>>          result = poll(&pfd, 1, timeout);
> >>>>>>>>          if (result < 0 && errno == EINTR) {
> >>>>>>>>              if (timeout > 0) {
> >>>>>>>>                  gettimeofday(&t, NULL);
> >>>>>>>>                  newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
> >>>>>>>>                  timeout -= newtime - prevtime;
> >>>>>>>>                  if (timeout <= 0)
> >>>>>>>>                      return 0;
> >>>>>>>>                  prevtime = newtime;
> >>>>>>>>              }
> >>>>>>>>          } else {
> >>>>>>>>              return result;
> >>>>>>>>          }
> >>>>>>>>      }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> the NET_ReadWithTimeout is modified with.
> >>>>>>>>
> >>>>>>>>     while (timeout > 0) {
> >>>>>>>>          result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
> >>>>>>>>
> >>>>>>>> in any case there is the potential for multiple invocation of
> >>>>>>>> gettimeofday due to a need to make
> >>>>>>>> poll restartable,
> >>>>>>> Yes, and that is fine. Just no more than is already there.
> >>>>>>>
> >>>>>>> and adjust the originally specified timeout
> >>>>>>>> accordingly, and for the edge case
> >>>>>>>> after the non blocking read.
> >>>>>>> After an initial skim, your suggestion seems reasonable.
> >>>>>>>
> >>>>>>> -Chris.
> >>>>>>>
> >>>>>>>> regards
> >>>>>>>> Mark
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
> >>>>>>>>> Vyom,
> >>>>>>>>>
> >>>>>>>>>
> >> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> There is some concern about the potential performance effect, etc,
> >>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
> >>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
> >>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
> >>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
> >>>>>>>>> Or write a variant of NET_Timeout that takes a function to
> >>>>>>>>> execute. Rather than effectively two loops conditioned on the
> >>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
> >>>>>>>>> it seems worth considering / evaluating.
> >>>>>>>>>
> >>>>>>>>> -Chris.
> >>>>>>>>>
> >>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
> >>>>>>>>>> hi Dimitry,
> >>>>>>>>>>
> >>>>>>>>>> thanks for review, I did consider to use  a monotonically
> >>>>>>>>>> increasing
> >>>>>>>>>> clock like "clock_gettime" but  existing nearby
> >>>>>>>>>> code("NET_Timeout") uses
> >>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
> >>>>>>>>>> code.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Vyom
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
> >>>>>>>>>>> Vyom,
> >>>>>>>>>>>
> >>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
> >>>>>>>>>>> gettimeofday ?
> >>>>>>>>>>>
> >>>>>>>>>>> gettimeofday is affected by system time changes, so running ntpd
> >>>>>>>>>>> can
> >>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
> >>>>>>>>>>> expensive
> >>>>>>>>>>> syscall.
> >>>>>>>>>>>
> >>>>>>>>>>> -Dmitry
> >>>>>>>>>>>
> >>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
> >>>>>>>>>>>> please find the updated
> >>>>>>>>>>>>
> >> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
> >>>>>>>>>>>>
> >>>>>>>>>>>> I
> >>>>>>>>>>>> incorporated the review comments.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Vyom
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
> >>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>     perhaps there is an opportunity to do  some refactoring
> >>>>>>>>>>>>> here (...
> >>>>>>>>>>>>> for me a "goto " carries a code smell! )
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> along the lines
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> if (timeout) {
> >>>>>>>>>>>>>       nread =  NET_ReadWithTimeout(...);
> >>>>>>>>>>>>> } else {
> >>>>>>>>>>>>>        nread = NET_Read(...);
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
> >>>>>>>>>>>>> restructuring of
> >>>>>>>>>>>>> your goto loop
> >>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
> >>>>>>>>>>>>>             if (nread <= 0) {
> >>>>>>>>>>>>>                 if (nread == 0) {
> >>>>>>>>>>>>>                     JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>>>>>> "SocketTimeoutException",
> >>>>>>>>>>>>>                                 "Read timed out");
> >>>>>>>>>>>>>                 } else if (nread == -1) {
> >>>>>>>>>>>>>                     if (errno == EBADF) {
> >>>>>>>>>>>>>                          JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>>>>>> "SocketException", "Socket closed");
> >>>>>>>>>>>>>                     } else if (errno == ENOMEM) {
> >>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
> >>>>>>>>>>>>> "NET_Timeout
> >>>>>>>>>>>>> native heap allocation failed");
> >>>>>>>>>>>>>                     } else {
> >>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
> >>>>>>>>>>>>>                             (env, JNU_JAVANETPKG
> >>>>>>>>>>>>> "SocketException",
> >>>>>>>>>>>>> "select/poll failed");
> >>>>>>>>>>>>>                     }
> >>>>>>>>>>>>>                 }
> >>>>>>>>>>>>>                   // release buffer in main call flow
> >>>>>>>>>>>>> //              if (bufP != BUF) {
> >>>>>>>>>>>>> //                  free(bufP);
> >>>>>>>>>>>>> //             }
> >>>>>>>>>>>>>                nread = -1;
> >>>>>>>>>>>>>                break;
> >>>>>>>>>>>>>             } else {
> >>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
> >>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
> >>>>>>>>>>>>> EWOULDBLOCK))) {
> >>>>>>>>>>>>>                 gettimeofday(&t, NULL);
> >>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> >>>>>>>>>>>>> _timeout -= newtime - prevtime;
> >>>>>>>>>>>>> if(_timeout > 0){
> >>>>>>>>>>>>> prevtime = newtime;
> >>>>>>>>>>>>>                     }
> >>>>>>>>>>>>> } else { break; } } } return nread;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> e&oe
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> regards
> >>>>>>>>>>>>> Mark
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
> >>>>>>>>>>>>>> gentle reminder, please review the below code change.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
> >>>>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please review the code changes for below issue.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Bug         :
> >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> webrev    :
> >>>>>>>>>>>>>>>
> >> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
> with
> >>>>>>>>>>>>>>> "soTimeout" set.the implementation of
> >>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
> that
> >>>>>>>>>>>>>>> read()
> >>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page for
> >>>>>>>>>>>>>>> select
> >>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
> >>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
> >>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
> example
> >>>>>>>>>>>>>>> happen
> >>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
> >> checksum
> >>>>>>>>>>>>>>> and is
> >>>>>>>>>>>>>>> discarded.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>


From vyom.tewari at oracle.com  Thu Sep  8 03:19:49 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 8 Sep 2016 08:49:49 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
Message-ID: <57D0D8D5.5090809@oracle.com>

Hi All,

Please find the latest 
webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>).

I fixed the AIX flag issue and move some come common code to 
"net_util_md.c" file.

Thanks,
Vyom

On 9/8/2016 12:32 PM, Langer, Christoph wrote:
> Hi Vyom,
>
> ok, thanks. I have one addition to my proposal: I don't think there's a need for a global NET_GetCurrentTime function. This one should probably be a static function inside net_util_md.c (static long getCurrentTime()).
>
> Best
> Christoph
>
>> -----Original Message-----
>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
>> Sent: Mittwoch, 7. September 2016 18:31
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
>> soTimeout set
>>
>> Hi Chris,
>>
>> Sorry I was mostly focusing on our test  failure first, i will check
>> your suggestions.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
>>> Hi Vyom,
>>>
>>> did you have a look at my suggestions regarding AIX and refactoring? I can't
>> find none of it in the new webrev nor did you comment on it.
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
>> Vyom
>>>> Tewari
>>>> Sent: Mittwoch, 7. September 2016 17:10
>>>> To: Chris Hegarty <chris.hegarty at oracle.com>
>>>> Cc: net-dev at openjdk.java.net
>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>> with
>>>> soTimeout set
>>>>
>>>> Hi All,
>>>>
>>>> Please find the latest
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
>>>> there were some test failures in JPRT and Chris also pointed the same
>>>> issue in modified code. Now with latest code JPRT is clean.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> Please find the latest
>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
>>>>>> did some code refactoring, JPRT is in progress.
>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>>>> have an additional comment.
>>>>>
>>>>> If NET_ReadWithTimeout returns -1 because
>> NET_TimeoutWithCurrentTime
>>>>> returns <= 0, then a JNI pending exception will be set. So the code
>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>>>> immediately rather than continuing and possibly trying to set another
>>>>> JNI pending exception.
>>>>>
>>>>> One option is to check the return value from NET_ReadWithTimeout and
>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>>>> the setting of JNI pending exceptions in one place, towards the end
>>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
>>>>> handled in two places.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> I need help from some one to build and test latest changes on AIX, may
>>>>>> be Christoph can help.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>>>> Vyom,
>>>>>>>
>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please find the latest
>>>>>>>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
>>>>>>>> I
>>>>>>>> have incorporated the review comments.
>>>>>>> Your changes completely avoid NET_Timeout, which is quite complex on
>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>>>>>> select ). Also, select is used on Mac, which will use poll after your
>>>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>>>> the time of the original Mac port ).
>>>>>>>
>>>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>>>>>> to have a version that supports passing a function pointer, to run if
>>>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>>>>>> already done.
>>>>>>>>>
>>>>>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>>>>>>> current_time)
>>>>>>>>>>
>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct timeval *
>>>>>>>>>> current_time) {
>>>>>>>>>>       int result;
>>>>>>>>>>       struct timeval t;
>>>>>>>>>>       long prevtime, newtime;
>>>>>>>>>>       struct pollfd pfd;
>>>>>>>>>>       pfd.fd = s;
>>>>>>>>>>       pfd.events = POLLIN;
>>>>>>>>>>
>>>>>>>>>>       if (timeout > 0) {
>>>>>>>>>>           prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>>>       }
>>>>>>>>>>
>>>>>>>>>>       for(;;) {
>>>>>>>>>>           result = poll(&pfd, 1, timeout);
>>>>>>>>>>           if (result < 0 && errno == EINTR) {
>>>>>>>>>>               if (timeout > 0) {
>>>>>>>>>>                   gettimeofday(&t, NULL);
>>>>>>>>>>                   newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>>>>>                   timeout -= newtime - prevtime;
>>>>>>>>>>                   if (timeout <= 0)
>>>>>>>>>>                       return 0;
>>>>>>>>>>                   prevtime = newtime;
>>>>>>>>>>               }
>>>>>>>>>>           } else {
>>>>>>>>>>               return result;
>>>>>>>>>>           }
>>>>>>>>>>       }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>>>
>>>>>>>>>>      while (timeout > 0) {
>>>>>>>>>>           result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>>>
>>>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>>>> gettimeofday due to a need to make
>>>>>>>>>> poll restartable,
>>>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>>>
>>>>>>>>> and adjust the originally specified timeout
>>>>>>>>>> accordingly, and for the edge case
>>>>>>>>>> after the non blocking read.
>>>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>>>
>>>>>>>>> -Chris.
>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>>>> Vyom,
>>>>>>>>>>>
>>>>>>>>>>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>
>>>>>>>>>>> There is some concern about the potential performance effect, etc,
>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>>>
>>>>>>>>>>> -Chris.
>>>>>>>>>>>
>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>>>> hi Dimitry,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
>>>>>>>>>>>> increasing
>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
>>>>>>>>>>>> code.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Vyom
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> gettimeofday is affected by system time changes, so running ntpd
>>>>>>>>>>>>> can
>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>>>> expensive
>>>>>>>>>>>>> syscall.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>      perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>>>>>> here (...
>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>>>        nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>>>         nread = NET_Read(...);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>>>              if (nread <= 0) {
>>>>>>>>>>>>>>>                  if (nread == 0) {
>>>>>>>>>>>>>>>                      JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>>>                                  "Read timed out");
>>>>>>>>>>>>>>>                  } else if (nread == -1) {
>>>>>>>>>>>>>>>                      if (errno == EBADF) {
>>>>>>>>>>>>>>>                           JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>>>                      } else if (errno == ENOMEM) {
>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>>>                      } else {
>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>>>                              (env, JNU_JAVANETPKG
>>>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>>>                      }
>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>                    // release buffer in main call flow
>>>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>>>                 nread = -1;
>>>>>>>>>>>>>>>                 break;
>>>>>>>>>>>>>>>              } else {
>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>>>                  gettimeofday(&t, NULL);
>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>>>                      }
>>>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>>>
>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>>>>>>>>
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
>> with
>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
>> that
>>>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page for
>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, select()
>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading", while
>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
>> example
>>>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>>>> checksum
>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>


From vyom.tewari at oracle.com  Thu Sep  8 08:58:10 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 8 Sep 2016 14:28:10 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <57D0D8D5.5090809@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
Message-ID: <d3b976a9-ab9d-ed30-43f9-a85bf87897a7@oracle.com>

sending this mail again as my laptop clock got screwed.

Vyom


On Thursday 08 September 2016 08:49 AM, Vyom Tewari wrote:
> Hi All,
>
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html 
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>).
>
> I fixed the AIX flag issue and move some come common code to 
> "net_util_md.c" file.
>
> Thanks,
> Vyom
>
> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
>> Hi Vyom,
>>
>> ok, thanks. I have one addition to my proposal: I don't think there's 
>> a need for a global NET_GetCurrentTime function. This one should 
>> probably be a static function inside net_util_md.c (static long 
>> getCurrentTime()).
>>
>> Best
>> Christoph
>>
>>> -----Original Message-----
>>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
>>> Sent: Mittwoch, 7. September 2016 18:31
>>> To: Langer, Christoph <christoph.langer at sap.com>
>>> Cc: net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even 
>>> with
>>> soTimeout set
>>>
>>> Hi Chris,
>>>
>>> Sorry I was mostly focusing on our test  failure first, i will check
>>> your suggestions.
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
>>>> Hi Vyom,
>>>>
>>>> did you have a look at my suggestions regarding AIX and 
>>>> refactoring? I can't
>>> find none of it in the new webrev nor did you comment on it.
>>>> Best regards
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
>>> Vyom
>>>>> Tewari
>>>>> Sent: Mittwoch, 7. September 2016 17:10
>>>>> To: Chris Hegarty <chris.hegarty at oracle.com>
>>>>> Cc: net-dev at openjdk.java.net
>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>> with
>>>>> soTimeout set
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Please find the latest
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html 
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>). 
>>>>>
>>>>> there were some test failures in JPRT and Chris also pointed the same
>>>>> issue in modified code. Now with latest code JPRT is clean.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> Please find the latest
>>>>>>>
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). 
>>> I
>>>>>>> did some code refactoring, JPRT is in progress.
>>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>>>>> have an additional comment.
>>>>>>
>>>>>> If NET_ReadWithTimeout returns -1 because
>>> NET_TimeoutWithCurrentTime
>>>>>> returns <= 0, then a JNI pending exception will be set. So the code
>>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>>>>> immediately rather than continuing and possibly trying to set 
>>>>>> another
>>>>>> JNI pending exception.
>>>>>>
>>>>>> One option is to check the return value from NET_ReadWithTimeout and
>>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>>>>> the setting of JNI pending exceptions in one place, towards the end
>>>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF is
>>>>>> handled in two places.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>> I need help from some one to build and test latest changes on 
>>>>>>> AIX, may
>>>>>>> be Christoph can help.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>>>>> Vyom,
>>>>>>>>
>>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please find the latest
>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html 
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>). 
>>>>>
>>>>>>>>> I
>>>>>>>>> have incorporated the review comments.
>>>>>>>> Your changes completely avoid NET_Timeout, which is quite 
>>>>>>>> complex on
>>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will 
>>>>>>>> use the
>>>>>>>> async close mechanism to signal/interrupt a thread blocked in a 
>>>>>>>> poll /
>>>>>>>> select ). Also, select is used on Mac, which will use poll 
>>>>>>>> after your
>>>>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>>>>> the time of the original Mac port ).
>>>>>>>>
>>>>>>>> Would is be better, rather than replicating the logic in 
>>>>>>>> NET_Timeout,
>>>>>>>> to have a version that supports passing a function pointer, to 
>>>>>>>> run if
>>>>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>>>>> if the desire is to avoid making double calls on 
>>>>>>>>>>> gettimeofday in the
>>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, 
>>>>>>>>>> than are
>>>>>>>>>> already done.
>>>>>>>>>>
>>>>>>>>>>> then consider a modification to NET_Timeout and create a 
>>>>>>>>>>> version
>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct 
>>>>>>>>>>> timeval *
>>>>>>>>>>> current_time)
>>>>>>>>>>>
>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct 
>>>>>>>>>>> timeval *
>>>>>>>>>>> current_time) {
>>>>>>>>>>>       int result;
>>>>>>>>>>>       struct timeval t;
>>>>>>>>>>>       long prevtime, newtime;
>>>>>>>>>>>       struct pollfd pfd;
>>>>>>>>>>>       pfd.fd = s;
>>>>>>>>>>>       pfd.events = POLLIN;
>>>>>>>>>>>
>>>>>>>>>>>       if (timeout > 0) {
>>>>>>>>>>>           prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>>>>       }
>>>>>>>>>>>
>>>>>>>>>>>       for(;;) {
>>>>>>>>>>>           result = poll(&pfd, 1, timeout);
>>>>>>>>>>>           if (result < 0 && errno == EINTR) {
>>>>>>>>>>>               if (timeout > 0) {
>>>>>>>>>>>                   gettimeofday(&t, NULL);
>>>>>>>>>>>                   newtime = (t.tv_sec * 1000) + t.tv_usec 
>>>>>>>>>>> /1000;
>>>>>>>>>>>                   timeout -= newtime - prevtime;
>>>>>>>>>>>                   if (timeout <= 0)
>>>>>>>>>>>                       return 0;
>>>>>>>>>>>                   prevtime = newtime;
>>>>>>>>>>>               }
>>>>>>>>>>>           } else {
>>>>>>>>>>>               return result;
>>>>>>>>>>>           }
>>>>>>>>>>>       }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>>>>
>>>>>>>>>>>      while (timeout > 0) {
>>>>>>>>>>>           result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>>>>
>>>>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>>>>> gettimeofday due to a need to make
>>>>>>>>>>> poll restartable,
>>>>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>>>>
>>>>>>>>>> and adjust the originally specified timeout
>>>>>>>>>>> accordingly, and for the edge case
>>>>>>>>>>> after the non blocking read.
>>>>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>>>>
>>>>>>>>>> -Chris.
>>>>>>>>>>
>>>>>>>>>>> regards
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> There is some concern about the potential performance 
>>>>>>>>>>>> effect, etc,
>>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The 
>>>>>>>>>>>> reuse of
>>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It 
>>>>>>>>>>>> seems that
>>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible 
>>>>>>>>>>>> operation.
>>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, 
>>>>>>>>>>>> but
>>>>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>>>>
>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>
>>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>>>>> hi Dimitry,
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks for review, I did consider to use a monotonically
>>>>>>>>>>>>> increasing
>>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the 
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you consider to use select() to calculate timeout 
>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> gettimeofday is affected by system time changes, so 
>>>>>>>>>>>>>> running ntpd
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>>>>> expensive
>>>>>>>>>>>>>> syscall.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html 
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>). 
>>>>>
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>      perhaps there is an opportunity to do  some 
>>>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>> here (...
>>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>>>>        nread = NET_ReadWithTimeout(...);
>>>>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>>>>         nread = NET_Read(...);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>>>>              if (nread <= 0) {
>>>>>>>>>>>>>>>>                  if (nread == 0) {
>>>>>>>>>>>>>>>> JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>>>> "Read timed out");
>>>>>>>>>>>>>>>>                  } else if (nread == -1) {
>>>>>>>>>>>>>>>>                      if (errno == EBADF) {
>>>>>>>>>>>>>>>> JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>>>>                      } else if (errno == ENOMEM) {
>>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>>>>                      } else {
>>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>>>>                              (env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>>>>                      }
>>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>>                    // release buffer in main call flow
>>>>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>>>>                 nread = -1;
>>>>>>>>>>>>>>>>                 break;
>>>>>>>>>>>>>>>>              } else {
>>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>>>> gettimeofday(&t, NULL);
>>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>>>>                      }
>>>>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>>>>
>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>>>>>>>>>>>
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
>>> with
>>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
>>> that
>>>>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is 
>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man 
>>>>>>>>>>>>>>>>>> page for
>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux, 
>>>>>>>>>>>>>>>>>> select()
>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for 
>>>>>>>>>>>>>>>>>> reading", while
>>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
>>> example
>>>>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>>>>> checksum
>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>


From christoph.langer at sap.com  Thu Sep  8 09:20:07 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 8 Sep 2016 09:20:07 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <57D0D8D5.5090809@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
Message-ID: <fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>

Hi Vyom,

this looks good.

Is there any particular reason why NET_ReadWithTimeout should remain in SocketInputStream.c and not also move to net_util_md.c? That way you could also have a "static long getCurrentTime()" inside net_util_md.c, instead of an exported NET_GetCurrentTime().

And no "#include <sys/time.h>" would be needed in SocketInputStream.c - maybe not even now as it is.

Best regards
Christoph

> -----Original Message-----
> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
> Sent: Donnerstag, 8. September 2016 05:20
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Hi All,
> 
> Please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>).
> 
> I fixed the AIX flag issue and move some come common code to
> "net_util_md.c" file.
> 
> Thanks,
> Vyom
> 
> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
> > Hi Vyom,
> >
> > ok, thanks. I have one addition to my proposal: I don't think there's a need for
> a global NET_GetCurrentTime function. This one should probably be a static
> function inside net_util_md.c (static long getCurrentTime()).
> >
> > Best
> > Christoph
> >
> >> -----Original Message-----
> >> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
> >> Sent: Mittwoch, 7. September 2016 18:31
> >> To: Langer, Christoph <christoph.langer at sap.com>
> >> Cc: net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
> >> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
> with
> >> soTimeout set
> >>
> >> Hi Chris,
> >>
> >> Sorry I was mostly focusing on our test  failure first, i will check
> >> your suggestions.
> >>
> >> Thanks,
> >>
> >> Vyom
> >>
> >>
> >> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
> >>> Hi Vyom,
> >>>
> >>> did you have a look at my suggestions regarding AIX and refactoring? I
> can't
> >> find none of it in the new webrev nor did you comment on it.
> >>> Best regards
> >>> Christoph
> >>>
> >>>> -----Original Message-----
> >>>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
> >> Vyom
> >>>> Tewari
> >>>> Sent: Mittwoch, 7. September 2016 17:10
> >>>> To: Chris Hegarty <chris.hegarty at oracle.com>
> >>>> Cc: net-dev at openjdk.java.net
> >>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
> >> with
> >>>> soTimeout set
> >>>>
> >>>> Hi All,
> >>>>
> >>>> Please find the latest
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
> >>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
> >>>> there were some test failures in JPRT and Chris also pointed the same
> >>>> issue in modified code. Now with latest code JPRT is clean.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Vyom
> >>>>
> >>>>
> >>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
> >>>>> On 07/09/16 07:45, Vyom Tewari wrote:
> >>>>>> Hi Chris,
> >>>>>>
> >>>>>> Please find the latest
> >>>>>>
> >> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> >> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
> >>>>>> did some code refactoring, JPRT is in progress.
> >>>>> In terms of NET_Timeout**, I'm happy with this version, but I
> >>>>> have an additional comment.
> >>>>>
> >>>>> If NET_ReadWithTimeout returns -1 because
> >> NET_TimeoutWithCurrentTime
> >>>>> returns <= 0, then a JNI pending exception will be set. So the code
> >>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
> >>>>> immediately rather than continuing and possibly trying to set another
> >>>>> JNI pending exception.
> >>>>>
> >>>>> One option is to check the return value from NET_ReadWithTimeout and
> >>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
> >>>>> the setting of JNI pending exceptions in one place, towards the end
> >>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF
> is
> >>>>> handled in two places.
> >>>>>
> >>>>> -Chris.
> >>>>>
> >>>>>> I need help from some one to build and test latest changes on AIX, may
> >>>>>> be Christoph can help.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Vyom
> >>>>>>
> >>>>>>
> >>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> >>>>>>> Vyom,
> >>>>>>>
> >>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
> >> wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Please find the latest
> >>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> >>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
> >>>>>>>> I
> >>>>>>>> have incorporated the review comments.
> >>>>>>> Your changes completely avoid NET_Timeout, which is quite complex
> on
> >>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
> >>>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
> >>>>>>> select ). Also, select is used on Mac, which will use poll after your
> >>>>>>> changes ( I do remember that there was a bug in poll on Mac around
> >>>>>>> the time of the original Mac port ).
> >>>>>>>
> >>>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
> >>>>>>> to have a version that supports passing a function pointer, to run if
> >>>>>>> the poll/select returns before the timeout? Just an idea.
> >>>>>>>
> >>>>>>> -Chris.
> >>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Vyom
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> >>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
> >>>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
> >>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
> >>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
> >>>>>>>>> already done.
> >>>>>>>>>
> >>>>>>>>>> then consider a modification to NET_Timeout and create a version
> >>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
> timeval *
> >>>>>>>>>> current_time)
> >>>>>>>>>>
> >>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
> timeval *
> >>>>>>>>>> current_time) {
> >>>>>>>>>>       int result;
> >>>>>>>>>>       struct timeval t;
> >>>>>>>>>>       long prevtime, newtime;
> >>>>>>>>>>       struct pollfd pfd;
> >>>>>>>>>>       pfd.fd = s;
> >>>>>>>>>>       pfd.events = POLLIN;
> >>>>>>>>>>
> >>>>>>>>>>       if (timeout > 0) {
> >>>>>>>>>>           prevtime = (current_time->tv_sec * 1000)  +
> >>>>>>>>>> current_time->tv_usec / 1000;
> >>>>>>>>>>       }
> >>>>>>>>>>
> >>>>>>>>>>       for(;;) {
> >>>>>>>>>>           result = poll(&pfd, 1, timeout);
> >>>>>>>>>>           if (result < 0 && errno == EINTR) {
> >>>>>>>>>>               if (timeout > 0) {
> >>>>>>>>>>                   gettimeofday(&t, NULL);
> >>>>>>>>>>                   newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
> >>>>>>>>>>                   timeout -= newtime - prevtime;
> >>>>>>>>>>                   if (timeout <= 0)
> >>>>>>>>>>                       return 0;
> >>>>>>>>>>                   prevtime = newtime;
> >>>>>>>>>>               }
> >>>>>>>>>>           } else {
> >>>>>>>>>>               return result;
> >>>>>>>>>>           }
> >>>>>>>>>>       }
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> the NET_ReadWithTimeout is modified with.
> >>>>>>>>>>
> >>>>>>>>>>      while (timeout > 0) {
> >>>>>>>>>>           result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
> >>>>>>>>>>
> >>>>>>>>>> in any case there is the potential for multiple invocation of
> >>>>>>>>>> gettimeofday due to a need to make
> >>>>>>>>>> poll restartable,
> >>>>>>>>> Yes, and that is fine. Just no more than is already there.
> >>>>>>>>>
> >>>>>>>>> and adjust the originally specified timeout
> >>>>>>>>>> accordingly, and for the edge case
> >>>>>>>>>> after the non blocking read.
> >>>>>>>>> After an initial skim, your suggestion seems reasonable.
> >>>>>>>>>
> >>>>>>>>> -Chris.
> >>>>>>>>>
> >>>>>>>>>> regards
> >>>>>>>>>> Mark
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
> >>>>>>>>>>> Vyom,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>>>>
> >>>>>>>>>>> There is some concern about the potential performance effect,
> etc,
> >>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
> >>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
> >>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
> >>>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
> >>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
> >>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
> >>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
> >>>>>>>>>>> it seems worth considering / evaluating.
> >>>>>>>>>>>
> >>>>>>>>>>> -Chris.
> >>>>>>>>>>>
> >>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
> >>>>>>>>>>>> hi Dimitry,
> >>>>>>>>>>>>
> >>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
> >>>>>>>>>>>> increasing
> >>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
> >>>>>>>>>>>> code("NET_Timeout") uses
> >>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
> >>>>>>>>>>>> code.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Vyom
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff
> wrote:
> >>>>>>>>>>>>> Vyom,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
> >>>>>>>>>>>>> gettimeofday ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> gettimeofday is affected by system time changes, so running
> ntpd
> >>>>>>>>>>>>> can
> >>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
> >>>>>>>>>>>>> expensive
> >>>>>>>>>>>>> syscall.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Dmitry
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
> >>>>>>>>>>>>>> please find the updated
> >>>>>>>>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>> incorporated the review comments.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
> >>>>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>>>      perhaps there is an opportunity to do  some refactoring
> >>>>>>>>>>>>>>> here (...
> >>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> along the lines
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> if (timeout) {
> >>>>>>>>>>>>>>>        nread =  NET_ReadWithTimeout(...);
> >>>>>>>>>>>>>>> } else {
> >>>>>>>>>>>>>>>         nread = NET_Read(...);
> >>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
> >>>>>>>>>>>>>>> restructuring of
> >>>>>>>>>>>>>>> your goto loop
> >>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
> >>>>>>>>>>>>>>>              if (nread <= 0) {
> >>>>>>>>>>>>>>>                  if (nread == 0) {
> >>>>>>>>>>>>>>>                      JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>>>>>>>> "SocketTimeoutException",
> >>>>>>>>>>>>>>>                                  "Read timed out");
> >>>>>>>>>>>>>>>                  } else if (nread == -1) {
> >>>>>>>>>>>>>>>                      if (errno == EBADF) {
> >>>>>>>>>>>>>>>                           JNU_ThrowByName(env, JNU_JAVANETPKG
> >>>>>>>>>>>>>>> "SocketException", "Socket closed");
> >>>>>>>>>>>>>>>                      } else if (errno == ENOMEM) {
> >>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
> >>>>>>>>>>>>>>> "NET_Timeout
> >>>>>>>>>>>>>>> native heap allocation failed");
> >>>>>>>>>>>>>>>                      } else {
> >>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
> >>>>>>>>>>>>>>>                              (env, JNU_JAVANETPKG
> >>>>>>>>>>>>>>> "SocketException",
> >>>>>>>>>>>>>>> "select/poll failed");
> >>>>>>>>>>>>>>>                      }
> >>>>>>>>>>>>>>>                  }
> >>>>>>>>>>>>>>>                    // release buffer in main call flow
> >>>>>>>>>>>>>>> //              if (bufP != BUF) {
> >>>>>>>>>>>>>>> //                  free(bufP);
> >>>>>>>>>>>>>>> //             }
> >>>>>>>>>>>>>>>                 nread = -1;
> >>>>>>>>>>>>>>>                 break;
> >>>>>>>>>>>>>>>              } else {
> >>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
> >>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
> >>>>>>>>>>>>>>> EWOULDBLOCK))) {
> >>>>>>>>>>>>>>>                  gettimeofday(&t, NULL);
> >>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> >>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
> >>>>>>>>>>>>>>> if(_timeout > 0){
> >>>>>>>>>>>>>>> prevtime = newtime;
> >>>>>>>>>>>>>>>                      }
> >>>>>>>>>>>>>>> } else { break; } } } return nread;
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> e&oe
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> regards
> >>>>>>>>>>>>>>> Mark
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
> >>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
> >>>>>>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Please review the code changes for below issue.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Bug         :
> >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> webrev    :
> >>>>>>>>>>>>>>>>>
> >>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> >>>>>>>>>>>>>>>>>
> >>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
> >> with
> >>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
> >>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
> >> that
> >>>>>>>>>>>>>>>>> read()
> >>>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page
> for
> >>>>>>>>>>>>>>>>> select
> >>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux,
> select()
> >>>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading",
> while
> >>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
> >> example
> >>>>>>>>>>>>>>>>> happen
> >>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
> >>>> checksum
> >>>>>>>>>>>>>>>>> and is
> >>>>>>>>>>>>>>>>> discarded.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>


From vyom.tewari at oracle.com  Thu Sep  8 09:43:05 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 8 Sep 2016 15:13:05 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<62220819-ff03-745d-75d8-8846343bd554@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
	<fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>
Message-ID: <78be3b64-60c6-e359-aeb1-7bc04d3655be@oracle.com>


On Thursday 08 September 2016 02:50 PM, Langer, Christoph wrote:
> Hi Vyom,
>
> this looks good.
>
> Is there any particular reason why NET_ReadWithTimeout should remain in SocketInputStream.c and not also move to net_util_md.c? That way you could also have a "static long getCurrentTime()" inside net_util_md.c, instead of an exported NET_GetCurrentTime().
I thought this "NET_ReadWithTimeou" is specific to SocketInputStream so 
i will be good if we put this method to socketinputstream.c.

In future we will in using the monotonic increasing clock so 
"NET_GetCurrentTime()" will help , Just change the implementation you 
are done.

Vyom
> And no "#include <sys/time.h>" would be needed in SocketInputStream.c - maybe not even now as it is.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
>> Sent: Donnerstag, 8. September 2016 05:20
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: net-dev at openjdk.java.net
>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
>> soTimeout set
>>
>> Hi All,
>>
>> Please find the latest
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>).
>>
>> I fixed the AIX flag issue and move some come common code to
>> "net_util_md.c" file.
>>
>> Thanks,
>> Vyom
>>
>> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
>>> Hi Vyom,
>>>
>>> ok, thanks. I have one addition to my proposal: I don't think there's a need for
>> a global NET_GetCurrentTime function. This one should probably be a static
>> function inside net_util_md.c (static long getCurrentTime()).
>>> Best
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
>>>> Sent: Mittwoch, 7. September 2016 18:31
>>>> To: Langer, Christoph <christoph.langer at sap.com>
>>>> Cc: net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>> with
>>>> soTimeout set
>>>>
>>>> Hi Chris,
>>>>
>>>> Sorry I was mostly focusing on our test  failure first, i will check
>>>> your suggestions.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
>>>>> Hi Vyom,
>>>>>
>>>>> did you have a look at my suggestions regarding AIX and refactoring? I
>> can't
>>>> find none of it in the new webrev nor did you comment on it.
>>>>> Best regards
>>>>> Christoph
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
>>>> Vyom
>>>>>> Tewari
>>>>>> Sent: Mittwoch, 7. September 2016 17:10
>>>>>> To: Chris Hegarty <chris.hegarty at oracle.com>
>>>>>> Cc: net-dev at openjdk.java.net
>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>>> with
>>>>>> soTimeout set
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Please find the latest
>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
>>>>>> there were some test failures in JPRT and Chris also pointed the same
>>>>>> issue in modified code. Now with latest code JPRT is clean.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> Please find the latest
>>>>>>>>
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
>>>>>>>> did some code refactoring, JPRT is in progress.
>>>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>>>>>> have an additional comment.
>>>>>>>
>>>>>>> If NET_ReadWithTimeout returns -1 because
>>>> NET_TimeoutWithCurrentTime
>>>>>>> returns <= 0, then a JNI pending exception will be set. So the code
>>>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>>>>>> immediately rather than continuing and possibly trying to set another
>>>>>>> JNI pending exception.
>>>>>>>
>>>>>>> One option is to check the return value from NET_ReadWithTimeout and
>>>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>>>>>> the setting of JNI pending exceptions in one place, towards the end
>>>>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF
>> is
>>>>>>> handled in two places.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>>> I need help from some one to build and test latest changes on AIX, may
>>>>>>>> be Christoph can help.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Vyom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>>>>>> Vyom,
>>>>>>>>>
>>>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please find the latest
>>>>>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
>>>>>>>>>> I
>>>>>>>>>> have incorporated the review comments.
>>>>>>>>> Your changes completely avoid NET_Timeout, which is quite complex
>> on
>>>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>>>>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>>>>>>>> select ). Also, select is used on Mac, which will use poll after your
>>>>>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>>>>>> the time of the original Mac port ).
>>>>>>>>>
>>>>>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>>>>>>>> to have a version that supports passing a function pointer, to run if
>>>>>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>>>>>
>>>>>>>>> -Chris.
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Vyom
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>>>>>>>> already done.
>>>>>>>>>>>
>>>>>>>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>> timeval *
>>>>>>>>>>>> current_time)
>>>>>>>>>>>>
>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>> timeval *
>>>>>>>>>>>> current_time) {
>>>>>>>>>>>>        int result;
>>>>>>>>>>>>        struct timeval t;
>>>>>>>>>>>>        long prevtime, newtime;
>>>>>>>>>>>>        struct pollfd pfd;
>>>>>>>>>>>>        pfd.fd = s;
>>>>>>>>>>>>        pfd.events = POLLIN;
>>>>>>>>>>>>
>>>>>>>>>>>>        if (timeout > 0) {
>>>>>>>>>>>>            prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>>>>>        }
>>>>>>>>>>>>
>>>>>>>>>>>>        for(;;) {
>>>>>>>>>>>>            result = poll(&pfd, 1, timeout);
>>>>>>>>>>>>            if (result < 0 && errno == EINTR) {
>>>>>>>>>>>>                if (timeout > 0) {
>>>>>>>>>>>>                    gettimeofday(&t, NULL);
>>>>>>>>>>>>                    newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>>>>>>>                    timeout -= newtime - prevtime;
>>>>>>>>>>>>                    if (timeout <= 0)
>>>>>>>>>>>>                        return 0;
>>>>>>>>>>>>                    prevtime = newtime;
>>>>>>>>>>>>                }
>>>>>>>>>>>>            } else {
>>>>>>>>>>>>                return result;
>>>>>>>>>>>>            }
>>>>>>>>>>>>        }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>>>>>
>>>>>>>>>>>>       while (timeout > 0) {
>>>>>>>>>>>>            result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>>>>>
>>>>>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>>>>>> gettimeofday due to a need to make
>>>>>>>>>>>> poll restartable,
>>>>>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>>>>>
>>>>>>>>>>> and adjust the originally specified timeout
>>>>>>>>>>>> accordingly, and for the edge case
>>>>>>>>>>>> after the non blocking read.
>>>>>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>>>>>
>>>>>>>>>>> -Chris.
>>>>>>>>>>>
>>>>>>>>>>>> regards
>>>>>>>>>>>> Mark
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>> There is some concern about the potential performance effect,
>> etc,
>>>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>>>>>> hi Dimitry,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
>>>>>>>>>>>>>> increasing
>>>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff
>> wrote:
>>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gettimeofday is affected by system time changes, so running
>> ntpd
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>>>>>> expensive
>>>>>>>>>>>>>>> syscall.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>>>>>
>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>>>>>
>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>       perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>>>>>>>> here (...
>>>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>>>>>         nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>>>>>          nread = NET_Read(...);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>>>>>               if (nread <= 0) {
>>>>>>>>>>>>>>>>>                   if (nread == 0) {
>>>>>>>>>>>>>>>>>                       JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>>>>>                                   "Read timed out");
>>>>>>>>>>>>>>>>>                   } else if (nread == -1) {
>>>>>>>>>>>>>>>>>                       if (errno == EBADF) {
>>>>>>>>>>>>>>>>>                            JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>>>>>                       } else if (errno == ENOMEM) {
>>>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>>>>>                       } else {
>>>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>>>>>                               (env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>>>>>                       }
>>>>>>>>>>>>>>>>>                   }
>>>>>>>>>>>>>>>>>                     // release buffer in main call flow
>>>>>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>>>>>                  nread = -1;
>>>>>>>>>>>>>>>>>                  break;
>>>>>>>>>>>>>>>>>               } else {
>>>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>>>>>                   gettimeofday(&t, NULL);
>>>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>>>>>                       }
>>>>>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>>>>>
>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
>>>> with
>>>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
>>>> that
>>>>>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page
>> for
>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux,
>> select()
>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading",
>> while
>>>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
>>>> example
>>>>>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>>>>>> checksum
>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160908/5298dd78/attachment-0001.html>

From sean.coffey at oracle.com  Thu Sep  8 15:08:52 2016
From: sean.coffey at oracle.com (Sean Coffey)
Date: Thu, 8 Sep 2016 16:08:52 +0100
Subject: RFR (XS):
	JDK-8165711:java/net/SetFactoryPermission/SetFactoryPermission.java
	needs to run in ovm mode
Message-ID: <348bfb7e-cd54-1d1b-572f-39d9a22ea27e@oracle.com>

Looking for review for this simple edit. Testcase should run in ovm mode.

https://bugs.openjdk.java.net/browse/JDK-8165711

patch :

diff --git 
a/test/java/net/SetFactoryPermission/SetFactoryPermission.java 
b/test/java/net/SetFactoryPermission/SetFactoryPermission.java
--- a/test/java/net/SetFactoryPermission/SetFactoryPermission.java
+++ b/test/java/net/SetFactoryPermission/SetFactoryPermission.java
@@ -27,7 +27,7 @@
   * @bug 8048052
   * @summary Test a series of methods which requires "setFactory" 
runtime permission
   * @modules java.rmi
- * @run main SetFactoryPermission success
+ * @run main/othervm SetFactoryPermission success
   * @run main/othervm/policy=policy.fail SetFactoryPermission fail
   * @run main/othervm/policy=policy.success SetFactoryPermission success
   */

regards,
Sean.


From chris.hegarty at oracle.com  Thu Sep  8 15:14:18 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 8 Sep 2016 16:14:18 +0100
Subject: RFR (XS):
	JDK-8165711:java/net/SetFactoryPermission/SetFactoryPermission.java
	needs to run in ovm mode
In-Reply-To: <348bfb7e-cd54-1d1b-572f-39d9a22ea27e@oracle.com>
References: <348bfb7e-cd54-1d1b-572f-39d9a22ea27e@oracle.com>
Message-ID: <2BCCC726-CCE1-4C59-A226-F6609F5CB74A@oracle.com>

Reviewed.

-Chris.

> On 8 Sep 2016, at 16:08, Sean Coffey <sean.coffey at oracle.com> wrote:
> 
> Looking for review for this simple edit. Testcase should run in ovm mode.
> 
> https://bugs.openjdk.java.net/browse/JDK-8165711
> 
> patch :
> 
> diff --git a/test/java/net/SetFactoryPermission/SetFactoryPermission.java b/test/java/net/SetFactoryPermission/SetFactoryPermission.java
> --- a/test/java/net/SetFactoryPermission/SetFactoryPermission.java
> +++ b/test/java/net/SetFactoryPermission/SetFactoryPermission.java
> @@ -27,7 +27,7 @@
>  * @bug 8048052
>  * @summary Test a series of methods which requires "setFactory" runtime permission
>  * @modules java.rmi
> - * @run main SetFactoryPermission success
> + * @run main/othervm SetFactoryPermission success
>  * @run main/othervm/policy=policy.fail SetFactoryPermission fail
>  * @run main/othervm/policy=policy.success SetFactoryPermission success
>  */
> 
> regards,
> Sean.
> 


From anthony.vanelverdinghe at gmail.com  Thu Sep  8 17:49:09 2016
From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe)
Date: Thu, 8 Sep 2016 19:49:09 +0200
Subject: HTTP client API
In-Reply-To: <57D04B47.1030805@oracle.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<57D04B47.1030805@oracle.com>
Message-ID: <2aa59e80-bb47-129a-c721-d1f86b0a5e61@gmail.com>

Hi Michael

What's the rationale for not turning all public classes into interfaces, 
since none of them contain any actual implementation code?

On another note, I fail to see the point of 
HttpClient.Builder::priority: as far as I understand, HTTP/2 priority 
only comes into play when multiple resources depend on the same 
resource. But since there's no way to express dependencies between 
resources, how would this be useful?

Lastly, some minor remarks: I believe the following factory methods 
should be moved for consistency
- HttpRequest::noBody --> HttpRequest.BodyProcessor::noBody
- HttpResponse::multiFile --> HttpResponse.MultiProcessor::asFiles

and that "? extends T" should be used instead of "T", in the return type 
of the following methods
- HttpResponse.BodyHandler::apply, i.e. BodyProcessor<? extends T>
- HttpResponse.BodyProcessor::getBody, i.e. CompletionStage<? extends T>
- HttpResponse.MultiProcessor::onRequest, i.e. Optional<BodyProcessor<? 
extends T>>

Kind regards,
Anthony


On 7/09/2016 19:15, Michael McMahon wrote:
> Hi Wenbo,
>
> First, sorry for the delay in replying. We took your comments and 
> prototyped how the major ones
> might be accommodated. In particular, we did the following:
>
> - moved "business logic" out of HttpRequest. The methods for sending 
> requests now
>    exist in HttpClient. Given that requests are no longer associated 
> with a client and can
>    be sent through any client, this means that some properties of a 
> request that used
>    to be inherited from the client can no longer be visible in the 
> HttpRequest object,
>    but that is not a problem as far as I can see. This changes the 
> look of the sample code
>    in HttpRequest, but doesn't make it any harder to read.
>
> - changed some method names as suggested eg newBuilder()
>
> - added protected constructors to the public classes. This allows 
> alternative implementations
>    for use in mocking/test frameworks etc.
>
> - changed the PUT, POST, GET methods in the request builder to only 
> set the method type.
>    PUT, POST takes the request body processor as parameter. A new 
> build() method returns
>    the HttpRequest.
>
> - added a method to HttpResponse which returns the "final" request 
> that was sent on the wire
>    for the particular response, which might be different from the user 
> initiated request.
>
> I put an updated apidoc [1] and specdiff [2] up to show the changes. 
> In particular, the sample
> code described in the HttpClient docs is updated to reflect the changes.
>
> Thanks,
> Michael
>
> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>
> [2] 
> http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html
>
> On 26/08/2016, 07:59, Wenbo Zhu wrote:
>> Hi Michael,
>>
>> Thanks for the update! The adoption of the Flow API is indeed a big 
>> improvement (async flow-control is very hard to get right).
>>
>> Attached is a feedback doc on this new version. One specific idea to 
>> discuss is whether it's possible to release the new HTTP client API 
>> as a standalone library (that works on JDK 9).
>>
>> Thanks,
>> Wenbo
>>
>>
>>
>> On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon 
>> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at 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.
>>
>>     Thanks,
>>
>>     Michael
>>
>>     [1] http://cr.openjdk.java.net/~michaelm/httpclient/api/
>>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/api/>
>>
>>     [2]
>>     http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout/package-summary.html
>>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/specdiffout/package-summary.html>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160908/6e7b5914/attachment.html>

From chris.hegarty at oracle.com  Thu Sep  8 19:40:12 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 8 Sep 2016 20:40:12 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <20160907131719.GA5531@vimes>
References: <20160907131719.GA5531@vimes>
Message-ID: <76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>


> On 7 Sep 2016, at 14:17, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> 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

I think that the source changes are good, but the tests has a
reference to a shell script that is absent. Also, could the test just
create a simple jar file, rather than checking in a binary artifact.

-Chris.

> In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
> 
> In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
> 
> 	-Rob


From rob.mckenna at oracle.com  Fri Sep  9 13:23:49 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 9 Sep 2016 14:23:49 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
References: <20160907131719.GA5531@vimes>
	<76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
Message-ID: <20160909132349.GA5159@vimes>

Hey Chris,

Apologies, I'm guilty of "just doing what adjacent tests do" here.

That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!

http://cr.openjdk.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 <rob.mckenna at oracle.com> wrote:
> > 
> > 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
> 
> I think that the source changes are good, but the tests has a
> reference to a shell script that is absent. Also, could the test just
> create a simple jar file, rather than checking in a binary artifact.
> 
> -Chris.
> 
> > In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
> > 
> > In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
> > 
> > 	-Rob
> 

From Roger.Riggs at Oracle.com  Fri Sep  9 15:00:32 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 9 Sep 2016 11:00:32 -0400
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <20160909132349.GA5159@vimes>
References: <20160907131719.GA5531@vimes>
	<76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
	<20160909132349.GA5159@vimes>
Message-ID: <f2d9f892-a68c-c538-781c-752091c63029@Oracle.com>

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, I'm guilty of "just doing what adjacent tests do" here.
>
> That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!
>
> http://cr.openjdk.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 <rob.mckenna at oracle.com> wrote:
>>>
>>> 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
>> I think that the source changes are good, but the tests has a
>> reference to a shell script that is absent. Also, could the test just
>> create a simple jar file, rather than checking in a binary artifact.
>>
>> -Chris.
>>
>>> In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
>>>
>>> In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
>>>
>>> 	-Rob


From rob.mckenna at oracle.com  Fri Sep  9 16:02:00 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 9 Sep 2016 17:02:00 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <f2d9f892-a68c-c538-781c-752091c63029@Oracle.com>
References: <20160907131719.GA5531@vimes>
	<76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
	<20160909132349.GA5159@vimes>
	<f2d9f892-a68c-c538-781c-752091c63029@Oracle.com>
Message-ID: <20160909160200.GB5159@vimes>

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, I'm guilty of "just doing what adjacent tests do" here.
> >
> >That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!
> >
> >http://cr.openjdk.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 <rob.mckenna at oracle.com> wrote:
> >>>
> >>>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
> >>I think that the source changes are good, but the tests has a
> >>reference to a shell script that is absent. Also, could the test just
> >>create a simple jar file, rather than checking in a binary artifact.
> >>
> >>-Chris.
> >>
> >>>In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
> >>>
> >>>In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
> >>>
> >>>	-Rob
> 

From rob.mckenna at oracle.com  Fri Sep  9 18:03:36 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 9 Sep 2016 19:03:36 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <20160909160200.GB5159@vimes>
References: <20160907131719.GA5531@vimes>
	<76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
	<20160909132349.GA5159@vimes>
	<f2d9f892-a68c-c538-781c-752091c63029@Oracle.com>
	<20160909160200.GB5159@vimes>
Message-ID: <20160909180336.GC5159@vimes>

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
> 
> 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, I'm guilty of "just doing what adjacent tests do" here.
> > >
> > >That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!
> > >
> > >http://cr.openjdk.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 <rob.mckenna at oracle.com> wrote:
> > >>>
> > >>>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
> > >>I think that the source changes are good, but the tests has a
> > >>reference to a shell script that is absent. Also, could the test just
> > >>create a simple jar file, rather than checking in a binary artifact.
> > >>
> > >>-Chris.
> > >>
> > >>>In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
> > >>>
> > >>>In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
> > >>>
> > >>>	-Rob
> > 

From rob.mckenna at oracle.com  Fri Sep  9 18:35:36 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 9 Sep 2016 19:35:36 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <20160909180336.GC5159@vimes>
References: <20160907131719.GA5531@vimes>
	<76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
	<20160909132349.GA5159@vimes>
	<f2d9f892-a68c-c538-781c-752091c63029@Oracle.com>
	<20160909160200.GB5159@vimes> <20160909180336.GC5159@vimes>
Message-ID: <20160909183536.GD5159@vimes>

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 scratch directory so the deleteOnExit wouldn't be needed either.
> 
> 	-Rob
> 
> On 09/09/16 05:02, Rob McKenna wrote:
> > 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, I'm guilty of "just doing what adjacent tests do" here.
> > > >
> > > >That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!
> > > >
> > > >http://cr.openjdk.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 <rob.mckenna at oracle.com> wrote:
> > > >>>
> > > >>>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
> > > >>I think that the source changes are good, but the tests has a
> > > >>reference to a shell script that is absent. Also, could the test just
> > > >>create a simple jar file, rather than checking in a binary artifact.
> > > >>
> > > >>-Chris.
> > > >>
> > > >>>In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
> > > >>>
> > > >>>In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
> > > >>>
> > > >>>	-Rob
> > > 

From chris.hegarty at oracle.com  Fri Sep  9 18:40:09 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 9 Sep 2016 19:40:09 +0100
Subject: RFR: 6947916: JarURLConnection does not handle useCaches correctly
In-Reply-To: <20160909183536.GD5159@vimes>
References: <20160907131719.GA5531@vimes>
	<76201CEB-7FB8-4342-9995-5C8C1F530E81@oracle.com>
	<20160909132349.GA5159@vimes>
	<f2d9f892-a68c-c538-781c-752091c63029@Oracle.com>
	<20160909160200.GB5159@vimes> <20160909180336.GC5159@vimes>
	<20160909183536.GD5159@vimes>
Message-ID: <111587AB-C17A-4D9D-9F5E-72AE8E7CB0A4@oracle.com>


> On 9 Sep 2016, at 19:35, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> To be explicit, new webrev here:
> 
> http://cr.openjdk.java.net/~robm/6947916/webrev.03/

Looks fine.

-Chris.

P.S. I?m ok if you want to explicitly delete the file either, just use the test library
FileUtils convenient method.


> 	-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 scratch directory so the deleteOnExit wouldn't be needed either.
>> 
>> 	-Rob
>> 
>> On 09/09/16 05:02, Rob McKenna wrote:
>>> 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, I'm guilty of "just doing what adjacent tests do" here.
>>>>> 
>>>>> That shell script is actually there in the test source already, but generating the jar from the test means theres no need to use it or to check in a binary. Thanks for picking me up!
>>>>> 
>>>>> http://cr.openjdk.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 <rob.mckenna at oracle.com> wrote:
>>>>>>> 
>>>>>>> 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
>>>>>> I think that the source changes are good, but the tests has a
>>>>>> reference to a shell script that is absent. Also, could the test just
>>>>>> create a simple jar file, rather than checking in a binary artifact.
>>>>>> 
>>>>>> -Chris.
>>>>>> 
>>>>>>> In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfortunately JarURLConnections connect() method recreates the jarFileURLConnection for a given JarURLConnection using the default value for getUseCaches instead of the *current* value.
>>>>>>> 
>>>>>>> In effect this means that jarURLConnection.getUseCaches() may return true before calling connect() and false after. This in turn means that when a JarURLConnection's inputstream is closed, it will believe that caching has been turned off and the underlying jarFile will be closed out from under all other JarURLConnection inputstreams.
>>>>>>> 
>>>>>>> 	-Rob
>>>> 


From vyom.tewari at oracle.com  Sun Sep 11 07:01:24 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Sun, 11 Sep 2016 12:31:24 +0530
Subject: RFR 8153674: Expected SocketException not thrown when calling bind()
	with setReuseAddress(false)
Message-ID: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>

Hi All,

Please review the below code change.

Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674

Webrev  : 
http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>

This change override the "get/setReuseAddress"  for MulticaseSocket and 
will abstract with both reuse attributes(SO_REUSEADDR & SO_REUSEPORT).

Thanks,

Vyom


From michael.x.mcmahon at oracle.com  Mon Sep 12 09:09:03 2016
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 12 Sep 2016 10:09:03 +0100
Subject: HTTP client API
In-Reply-To: <2aa59e80-bb47-129a-c721-d1f86b0a5e61@gmail.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<57D04B47.1030805@oracle.com>
	<2aa59e80-bb47-129a-c721-d1f86b0a5e61@gmail.com>
Message-ID: <57D670AF.7020701@oracle.com>

Hi Anthony,

On 08/09/2016, 18:49, Anthony Vanelverdinghe wrote:
> Hi Michael
>
> What's the rationale for not turning all public classes into 
> interfaces, since none of them contain any actual implementation code?
>
We could do that with little or no impact on the implementation or on 
calling code.
I will look into it.

> On another note, I fail to see the point of 
> HttpClient.Builder::priority: as far as I understand, HTTP/2 priority 
> only comes into play when multiple resources depend on the same 
> resource. But since there's no way to express dependencies between 
> resources, how would this be useful?
>
There was a desire expressed for the concept of a default priority, 
which would not have any impact on client
behavior, but could still affect the behavior of the server. Client 
applications might be able to differentiate
requests with different priorities by using different HttpClient instances.

> Lastly, some minor remarks: I believe the following factory methods 
> should be moved for consistency
> - HttpRequest::noBody --> HttpRequest.BodyProcessor::noBody
> - HttpResponse::multiFile --> HttpResponse.MultiProcessor::asFiles
>
> and that "? extends T" should be used instead of "T", in the return 
> type of the following methods
> - HttpResponse.BodyHandler::apply, i.e. BodyProcessor<? extends T>
> - HttpResponse.BodyProcessor::getBody, i.e. CompletionStage<? extends T>
> - HttpResponse.MultiProcessor::onRequest, i.e. 
> Optional<BodyProcessor<? extends T>>
>
Agreed on both points.

One other thing. I just want to acknowledge, since I haven't before, the 
work you did, prototyping
the change to the request and response processor API, and the use of the 
Flow Publisher and
Subscriber classes in particular. I think that has been a very useful 
addition to the API.

Thanks,
Michael
>
> On 7/09/2016 19:15, Michael McMahon wrote:
>> Hi Wenbo,
>>
>> First, sorry for the delay in replying. We took your comments and 
>> prototyped how the major ones
>> might be accommodated. In particular, we did the following:
>>
>> - moved "business logic" out of HttpRequest. The methods for sending 
>> requests now
>>    exist in HttpClient. Given that requests are no longer associated 
>> with a client and can
>>    be sent through any client, this means that some properties of a 
>> request that used
>>    to be inherited from the client can no longer be visible in the 
>> HttpRequest object,
>>    but that is not a problem as far as I can see. This changes the 
>> look of the sample code
>>    in HttpRequest, but doesn't make it any harder to read.
>>
>> - changed some method names as suggested eg newBuilder()
>>
>> - added protected constructors to the public classes. This allows 
>> alternative implementations
>>    for use in mocking/test frameworks etc.
>>
>> - changed the PUT, POST, GET methods in the request builder to only 
>> set the method type.
>>    PUT, POST takes the request body processor as parameter. A new 
>> build() method returns
>>    the HttpRequest.
>>
>> - added a method to HttpResponse which returns the "final" request 
>> that was sent on the wire
>>    for the particular response, which might be different from the 
>> user initiated request.
>>
>> I put an updated apidoc [1] and specdiff [2] up to show the changes. 
>> In particular, the sample
>> code described in the HttpClient docs is updated to reflect the changes.
>>
>> Thanks,
>> Michael
>>
>> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>>
>> [2] 
>> http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html
>>
>> On 26/08/2016, 07:59, Wenbo Zhu wrote:
>>> Hi Michael,
>>>
>>> Thanks for the update! The adoption of the Flow API is indeed a big 
>>> improvement (async flow-control is very hard to get right).
>>>
>>> Attached is a feedback doc on this new version. One specific idea to 
>>> discuss is whether it's possible to release the new HTTP client API 
>>> as a standalone library (that works on JDK 9).
>>>
>>> Thanks,
>>> Wenbo
>>>
>>>
>>>
>>> On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon 
>>> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at 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.
>>>
>>>     Thanks,
>>>
>>>     Michael
>>>
>>>     [1] http://cr.openjdk.java.net/~michaelm/httpclient/api/
>>>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/api/>
>>>
>>>     [2]
>>>     http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout/package-summary.html
>>>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/specdiffout/package-summary.html>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160912/4b0b8f76/attachment-0001.html>

From fweimer at redhat.com  Mon Sep 12 13:50:13 2016
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 12 Sep 2016 15:50:13 +0200
Subject: Introduce IOException subclass for ECONNRESET
In-Reply-To: <0456C96C-1FBA-4031-9845-54EC4D134A9B@googlemail.com>
References: <0456C96C-1FBA-4031-9845-54EC4D134A9B@googlemail.com>
Message-ID: <d6a37ff9-ba22-7e47-174e-154b33be9626@redhat.com>

On 08/23/2016 09: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 {
> }

Shouldn't it be a subclass of SocketException?

Thanks,
Florian


From chris.hegarty at oracle.com  Mon Sep 12 15:06:34 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 12 Sep 2016 16:06:34 +0100
Subject: Introduce IOException subclass for ECONNRESET
In-Reply-To: <d6a37ff9-ba22-7e47-174e-154b33be9626@redhat.com>
References: <0456C96C-1FBA-4031-9845-54EC4D134A9B@googlemail.com>
	<d6a37ff9-ba22-7e47-174e-154b33be9626@redhat.com>
Message-ID: <942a191e-f546-c80c-01f4-867c7e1f8a52@oracle.com>

On 12/09/16 14:50, Florian Weimer wrote:
> On 08/23/2016 09: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?.

So what are the other cases, where ECONNRESET may occur? What is
equivalent on non-Unix platforms, Windows for example?

 >> At the moment the only way to
>> detect this is to inspect the IOException message which is really
>> hacky.

Do you have examples of code that does this today?

>> I wonder if we could not add a special IOException sub-class
>> for this. Something like:
>>
>> ConnectionResetException extends IOException {
>> }
>
> Shouldn't it be a subclass of SocketException?

I think it would have to be a subclass of SocketException too, for
compatibility at least, since that is the type that is thrown
today.

sun.net.ConnectionResetException exists today, but I don't think
that it ever finds its way outside of the implementation. And is
of course not part of Java SE.

-Chris.



From vyom.tewari at oracle.com  Tue Sep 13 03:00:45 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 13 Sep 2016 08:30:45 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <78be3b64-60c6-e359-aeb1-7bc04d3655be@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
	<fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>
	<78be3b64-60c6-e359-aeb1-7bc04d3655be@oracle.com>
Message-ID: <4e7e4bf4-d2b7-5e96-e7ef-a6cbf98ddf1e@oracle.com>

any comment on latest 
webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>) ?

Vyom


On Thursday 08 September 2016 03:13 PM, Vyom Tewari wrote:
>
> On Thursday 08 September 2016 02:50 PM, Langer, Christoph wrote:
>> Hi Vyom,
>>
>> this looks good.
>>
>> Is there any particular reason why NET_ReadWithTimeout should remain in SocketInputStream.c and not also move to net_util_md.c? That way you could also have a "static long getCurrentTime()" inside net_util_md.c, instead of an exported NET_GetCurrentTime().
> I thought this "NET_ReadWithTimeou" is specific to SocketInputStream 
> so i will be good if we put this method to socketinputstream.c.
>
> In future we will in using the monotonic increasing clock so 
> "NET_GetCurrentTime()" will help , Just change the implementation you 
> are done.
>
> Vyom
>> And no "#include <sys/time.h>" would be needed in SocketInputStream.c - maybe not even now as it is.
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
>>> Sent: Donnerstag, 8. September 2016 05:20
>>> To: Langer, Christoph<christoph.langer at sap.com>
>>> Cc:net-dev at openjdk.java.net
>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
>>> soTimeout set
>>>
>>> Hi All,
>>>
>>> Please find the latest
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>).
>>>
>>> I fixed the AIX flag issue and move some come common code to
>>> "net_util_md.c" file.
>>>
>>> Thanks,
>>> Vyom
>>>
>>> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
>>>> Hi Vyom,
>>>>
>>>> ok, thanks. I have one addition to my proposal: I don't think there's a need for
>>> a global NET_GetCurrentTime function. This one should probably be a static
>>> function inside net_util_md.c (static long getCurrentTime()).
>>>> Best
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
>>>>> Sent: Mittwoch, 7. September 2016 18:31
>>>>> To: Langer, Christoph<christoph.langer at sap.com>
>>>>> Cc:net-dev at openjdk.java.net; Chris Hegarty<chris.hegarty at oracle.com>
>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>> with
>>>>> soTimeout set
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Sorry I was mostly focusing on our test  failure first, i will check
>>>>> your suggestions.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
>>>>>> Hi Vyom,
>>>>>>
>>>>>> did you have a look at my suggestions regarding AIX and refactoring? I
>>> can't
>>>>> find none of it in the new webrev nor did you comment on it.
>>>>>> Best regards
>>>>>> Christoph
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
>>>>> Vyom
>>>>>>> Tewari
>>>>>>> Sent: Mittwoch, 7. September 2016 17:10
>>>>>>> To: Chris Hegarty<chris.hegarty at oracle.com>
>>>>>>> Cc:net-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>>>> with
>>>>>>> soTimeout set
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please find the latest
>>>>>>>
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>).
>>>>>>> there were some test failures in JPRT and Chris also pointed the same
>>>>>>> issue in modified code. Now with latest code JPRT is clean.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> Please find the latest
>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>). I
>>>>>>>>> did some code refactoring, JPRT is in progress.
>>>>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>>>>>>> have an additional comment.
>>>>>>>>
>>>>>>>> If NET_ReadWithTimeout returns -1 because
>>>>> NET_TimeoutWithCurrentTime
>>>>>>>> returns <= 0, then a JNI pending exception will be set. So the code
>>>>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>>>>>>> immediately rather than continuing and possibly trying to set another
>>>>>>>> JNI pending exception.
>>>>>>>>
>>>>>>>> One option is to check the return value from NET_ReadWithTimeout and
>>>>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>>>>>>> the setting of JNI pending exceptions in one place, towards the end
>>>>>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF
>>> is
>>>>>>>> handled in two places.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>>> I need help from some one to build and test latest changes on AIX, may
>>>>>>>>> be Christoph can help.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>>>>>>> Vyom,
>>>>>>>>>>
>>>>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari<vyom.tewari at oracle.com>
>>>>> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please find the latest
>>>>>>>>>>>
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).
>>>>>>>>>>> I
>>>>>>>>>>> have incorporated the review comments.
>>>>>>>>>> Your changes completely avoid NET_Timeout, which is quite complex
>>> on
>>>>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>>>>>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>>>>>>>>> select ). Also, select is used on Mac, which will use poll after your
>>>>>>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>>>>>>> the time of the original Mac port ).
>>>>>>>>>>
>>>>>>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>>>>>>>>> to have a version that supports passing a function pointer, to run if
>>>>>>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>>>>>>
>>>>>>>>>> -Chris.
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Vyom
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>>>>>>>>> already done.
>>>>>>>>>>>>
>>>>>>>>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>>> timeval *
>>>>>>>>>>>>> current_time)
>>>>>>>>>>>>>
>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>>> timeval *
>>>>>>>>>>>>> current_time) {
>>>>>>>>>>>>>        int result;
>>>>>>>>>>>>>        struct timeval t;
>>>>>>>>>>>>>        long prevtime, newtime;
>>>>>>>>>>>>>        struct pollfd pfd;
>>>>>>>>>>>>>        pfd.fd = s;
>>>>>>>>>>>>>        pfd.events = POLLIN;
>>>>>>>>>>>>>
>>>>>>>>>>>>>        if (timeout > 0) {
>>>>>>>>>>>>>            prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>>>>>>        }
>>>>>>>>>>>>>
>>>>>>>>>>>>>        for(;;) {
>>>>>>>>>>>>>            result = poll(&pfd, 1, timeout);
>>>>>>>>>>>>>            if (result < 0 && errno == EINTR) {
>>>>>>>>>>>>>                if (timeout > 0) {
>>>>>>>>>>>>>                    gettimeofday(&t, NULL);
>>>>>>>>>>>>>                    newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>>>>>>>>                    timeout -= newtime - prevtime;
>>>>>>>>>>>>>                    if (timeout <= 0)
>>>>>>>>>>>>>                        return 0;
>>>>>>>>>>>>>                    prevtime = newtime;
>>>>>>>>>>>>>                }
>>>>>>>>>>>>>            } else {
>>>>>>>>>>>>>                return result;
>>>>>>>>>>>>>            }
>>>>>>>>>>>>>        }
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>>>>>>
>>>>>>>>>>>>>       while (timeout > 0) {
>>>>>>>>>>>>>            result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>>>>>>
>>>>>>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>>>>>>> gettimeofday due to a need to make
>>>>>>>>>>>>> poll restartable,
>>>>>>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>>>>>>
>>>>>>>>>>>> and adjust the originally specified timeout
>>>>>>>>>>>>> accordingly, and for the edge case
>>>>>>>>>>>>> after the non blocking read.
>>>>>>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>>>>>>
>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>
>>>>>>>>>>>>> regards
>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>>> There is some concern about the potential performance effect,
>>> etc,
>>>>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>>>>>>> hi Dimitry,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
>>>>>>>>>>>>>>> increasing
>>>>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff
>>> wrote:
>>>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gettimeofday is affected by system time changes, so running
>>> ntpd
>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>>>>>>> expensive
>>>>>>>>>>>>>>>> syscall.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>>>>>>
>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>).
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>       perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>>>>>>>>> here (...
>>>>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>>>>>>         nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>>>>>>          nread = NET_Read(...);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>>>>>>               if (nread <= 0) {
>>>>>>>>>>>>>>>>>>                   if (nread == 0) {
>>>>>>>>>>>>>>>>>>                       JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>>>>>>                                   "Read timed out");
>>>>>>>>>>>>>>>>>>                   } else if (nread == -1) {
>>>>>>>>>>>>>>>>>>                       if (errno == EBADF) {
>>>>>>>>>>>>>>>>>>                            JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>>>>>>                       } else if (errno == ENOMEM) {
>>>>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>>>>>>                       } else {
>>>>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>>>>>>                               (env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>>>>>>                       }
>>>>>>>>>>>>>>>>>>                   }
>>>>>>>>>>>>>>>>>>                     // release buffer in main call flow
>>>>>>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>>>>>>                  nread = -1;
>>>>>>>>>>>>>>>>>>                  break;
>>>>>>>>>>>>>>>>>>               } else {
>>>>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>>>>>>                   gettimeofday(&t, NULL);
>>>>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>>>>>>                       }
>>>>>>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
>>>>> with
>>>>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
>>>>> that
>>>>>>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page
>>> for
>>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux,
>>> select()
>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading",
>>> while
>>>>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
>>>>> example
>>>>>>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>>>>>>> checksum
>>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160913/20121f5d/attachment-0001.html>

From chris.hegarty at oracle.com  Tue Sep 13 08:47:58 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 13 Sep 2016 09:47:58 +0100
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <4e7e4bf4-d2b7-5e96-e7ef-a6cbf98ddf1e@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
	<fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>
	<78be3b64-60c6-e359-aeb1-7bc04d3655be@oracle.com> <4e7e!
	4bf4-d2b7-5e96-e7ef-a6cbf98ddf1e@oracle.com>
Message-ID: <D875ECB5-19A2-4352-BD1B-A3F243C1F782@oracle.com>

Vyom,

> On 13 Sep 2016, at 04:00, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> 
> any comment on latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html) ?

I am happy with the way this change turned out. Reviewed.

Trivially, before you push, just add a space to the four OS specific versions of 
Net_Timeout0, as follows:

  NET_Timeout0(int s, long timeout, long currentTime)
                                                       ^^^ 
Thanks,
-Chris.

> Vyom
> 
> On Thursday 08 September 2016 03:13 PM, Vyom Tewari wrote:
>> 
>> On Thursday 08 September 2016 02:50 PM, Langer, Christoph wrote:
>>> Hi Vyom,
>>> 
>>> this looks good.
>>> 
>>> Is there any particular reason why NET_ReadWithTimeout should remain in SocketInputStream.c and not also move to net_util_md.c? That way you could also have a "static long getCurrentTime()" inside net_util_md.c, instead of an exported NET_GetCurrentTime().
>>> 
>> I thought this "NET_ReadWithTimeou" is specific to SocketInputStream so i will be good if we put this method to socketinputstream.c.
>> 
>> In future we will in using the monotonic increasing clock so "NET_GetCurrentTime()" will help , Just change the implementation you are done.
>> 
>> Vyom
>>>  
>>> And no "#include <sys/time.h>" would be needed in SocketInputStream.c - maybe not even now as it is.
>>> 
>>> Best regards
>>> Christoph
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Vyom Tewari [
>>>> mailto:vyom.tewari at oracle.com
>>>> ]
>>>> Sent: Donnerstag, 8. September 2016 05:20
>>>> To: Langer, Christoph 
>>>> <christoph.langer at sap.com>
>>>> 
>>>> Cc: 
>>>> net-dev at openjdk.java.net
>>>> 
>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
>>>> soTimeout set
>>>> 
>>>> Hi All,
>>>> 
>>>> Please find the latest
>>>> webrev(
>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>
>>>> ).
>>>> 
>>>> I fixed the AIX flag issue and move some come common code to
>>>> "net_util_md.c" file.
>>>> 
>>>> Thanks,
>>>> Vyom
>>>> 
>>>> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
>>>> 
>>>>> Hi Vyom,
>>>>> 
>>>>> ok, thanks. I have one addition to my proposal: I don't think there's a need for
>>>>> 
>>>> a global NET_GetCurrentTime function. This one should probably be a static
>>>> function inside net_util_md.c (static long getCurrentTime()).
>>>> 
>>>>> Best
>>>>> Christoph
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Vyom Tewari [
>>>>>> mailto:vyom.tewari at oracle.com
>>>>>> ]
>>>>>> Sent: Mittwoch, 7. September 2016 18:31
>>>>>> To: Langer, Christoph 
>>>>>> <christoph.langer at sap.com>
>>>>>> 
>>>>>> Cc: 
>>>>>> net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
>>>>>> 
>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>>>>> 
>>>> with
>>>> 
>>>>>> soTimeout set
>>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> Sorry I was mostly focusing on our test  failure first, i will check
>>>>>> your suggestions.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Vyom
>>>>>> 
>>>>>> 
>>>>>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
>>>>>> 
>>>>>>> Hi Vyom,
>>>>>>> 
>>>>>>> did you have a look at my suggestions regarding AIX and refactoring? I
>>>>>>> 
>>>> can't
>>>> 
>>>>>> find none of it in the new webrev nor did you comment on it.
>>>>>> 
>>>>>>> Best regards
>>>>>>> Christoph
>>>>>>> 
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: net-dev [
>>>>>>>> mailto:net-dev-bounces at openjdk.java.net
>>>>>>>> ] On Behalf Of
>>>>>>>> 
>>>>>> Vyom
>>>>>> 
>>>>>>>> Tewari
>>>>>>>> Sent: Mittwoch, 7. September 2016 17:10
>>>>>>>> To: Chris Hegarty 
>>>>>>>> <chris.hegarty at oracle.com>
>>>>>>>> 
>>>>>>>> Cc: 
>>>>>>>> net-dev at openjdk.java.net
>>>>>>>> 
>>>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>>>>>>> 
>>>>>> with
>>>>>> 
>>>>>>>> soTimeout set
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Please find the latest
>>>>>>>> 
>>>>>>>> 
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>
>>>> ).
>>>> 
>>>>>>>> there were some test failures in JPRT and Chris also pointed the same
>>>>>>>> issue in modified code. Now with latest code JPRT is clean.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Vyom
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>>>>>> 
>>>>>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>>>>>>> 
>>>>>>>>>> Hi Chris,
>>>>>>>>>> 
>>>>>>>>>> Please find the latest
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>
>>>>>> ). I
>>>>>> 
>>>>>>>>>> did some code refactoring, JPRT is in progress.
>>>>>>>>>> 
>>>>>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>>>>>>>> have an additional comment.
>>>>>>>>> 
>>>>>>>>> If NET_ReadWithTimeout returns -1 because
>>>>>>>>> 
>>>>>> NET_TimeoutWithCurrentTime
>>>>>> 
>>>>>>>>> returns <= 0, then a JNI pending exception will be set. So the code
>>>>>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>>>>>>>> immediately rather than continuing and possibly trying to set another
>>>>>>>>> JNI pending exception.
>>>>>>>>> 
>>>>>>>>> One option is to check the return value from NET_ReadWithTimeout and
>>>>>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>>>>>>>> the setting of JNI pending exceptions in one place, towards the end
>>>>>>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF
>>>>>>>>> 
>>>> is
>>>> 
>>>>>>>>> handled in two places.
>>>>>>>>> 
>>>>>>>>> -Chris.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> I need help from some one to build and test latest changes on AIX, may
>>>>>>>>>> be Christoph can help.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Vyom
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>>>>>>> 
>>>>>>>>>>> Vyom,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
>>>>>> wrote:
>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> Please find the latest
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>
>>>> ).
>>>> 
>>>>>>>>>>>> I
>>>>>>>>>>>> have incorporated the review comments.
>>>>>>>>>>>> 
>>>>>>>>>>> Your changes completely avoid NET_Timeout, which is quite complex
>>>>>>>>>>> 
>>>> on
>>>> 
>>>>>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>>>>>>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>>>>>>>>>> select ). Also, select is used on Mac, which will use poll after your
>>>>>>>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>>>>>>>> the time of the original Mac port ).
>>>>>>>>>>> 
>>>>>>>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>>>>>>>>>> to have a version that supports passing a function pointer, to run if
>>>>>>>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>>>>>>> 
>>>>>>>>>>> -Chris.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> 
>>>>>>>>>>>> Vyom
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>>>>>>>>>> already done.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>>>>>>>>>>>>>> 
>>>> timeval *
>>>> 
>>>>>>>>>>>>>> current_time)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>>>>>>>>>>>>>> 
>>>> timeval *
>>>> 
>>>>>>>>>>>>>> current_time) {
>>>>>>>>>>>>>>       int result;
>>>>>>>>>>>>>>       struct timeval t;
>>>>>>>>>>>>>>       long prevtime, newtime;
>>>>>>>>>>>>>>       struct pollfd pfd;
>>>>>>>>>>>>>>       pfd.fd = s;
>>>>>>>>>>>>>>       pfd.events = POLLIN;
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>       if (timeout > 0) {
>>>>>>>>>>>>>>           prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>>>>>>>       }
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>       for(;;) {
>>>>>>>>>>>>>>           result = poll(&pfd, 1, timeout);
>>>>>>>>>>>>>>           if (result < 0 && errno == EINTR) {
>>>>>>>>>>>>>>               if (timeout > 0) {
>>>>>>>>>>>>>>                   gettimeofday(&t, NULL);
>>>>>>>>>>>>>>                   newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>>>>>>>>>                   timeout -= newtime - prevtime;
>>>>>>>>>>>>>>                   if (timeout <= 0)
>>>>>>>>>>>>>>                       return 0;
>>>>>>>>>>>>>>                   prevtime = newtime;
>>>>>>>>>>>>>>               }
>>>>>>>>>>>>>>           } else {
>>>>>>>>>>>>>>               return result;
>>>>>>>>>>>>>>           }
>>>>>>>>>>>>>>       }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>      while (timeout > 0) {
>>>>>>>>>>>>>>           result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>>>>>>>> gettimeofday due to a need to make
>>>>>>>>>>>>>> poll restartable,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> and adjust the originally specified timeout
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> accordingly, and for the edge case
>>>>>>>>>>>>>> after the non blocking read.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>>>> There is some concern about the potential performance effect,
>>>>>>>>>>>>>>> 
>>>> etc,
>>>> 
>>>>>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> hi Dimitry,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
>>>>>>>>>>>>>>>> increasing
>>>>>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff
>>>>>>>>>>>>>>>> 
>>>> wrote:
>>>> 
>>>>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> gettimeofday is affected by system time changes, so running
>>>>>>>>>>>>>>>>> 
>>>> ntpd
>>>> 
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>>>>>>>> expensive
>>>>>>>>>>>>>>>>> syscall.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>
>>>> ).
>>>> 
>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>>      perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>>>>>>>>>> here (...
>>>>>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>>>>>>>        nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>>>>>>>         nread = NET_Read(...);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>>>>>>>              if (nread <= 0) {
>>>>>>>>>>>>>>>>>>>                  if (nread == 0) {
>>>>>>>>>>>>>>>>>>>                      JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>>>>>>>                                  "Read timed out");
>>>>>>>>>>>>>>>>>>>                  } else if (nread == -1) {
>>>>>>>>>>>>>>>>>>>                      if (errno == EBADF) {
>>>>>>>>>>>>>>>>>>>                           JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>>>>>>>                      } else if (errno == ENOMEM) {
>>>>>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>>>>>>>                      } else {
>>>>>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>>>>>>>                              (env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>>>>>>>                      }
>>>>>>>>>>>>>>>>>>>                  }
>>>>>>>>>>>>>>>>>>>                    // release buffer in main call flow
>>>>>>>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>>>>>>>                 nread = -1;
>>>>>>>>>>>>>>>>>>>                 break;
>>>>>>>>>>>>>>>>>>>              } else {
>>>>>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>>>>>>>                  gettimeofday(&t, NULL);
>>>>>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>>>>>>>                      }
>>>>>>>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
>>>>>>>>>>>>>>>>>>>>> 
>>>>>> with
>>>>>> 
>>>>>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
>>>>>>>>>>>>>>>>>>>>> 
>>>>>> that
>>>>>> 
>>>>>>>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page
>>>>>>>>>>>>>>>>>>>>> 
>>>> for
>>>> 
>>>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux,
>>>>>>>>>>>>>>>>>>>>> 
>>>> select()
>>>> 
>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading",
>>>>>>>>>>>>>>>>>>>>> 
>>>> while
>>>> 
>>>>>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
>>>>>>>>>>>>>>>>>>>>> 
>>>>>> example
>>>>>> 
>>>>>>>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>> checksum
>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>> 
> 


From christoph.langer at sap.com  Tue Sep 13 08:58:10 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 13 Sep 2016 08:58:10 +0000
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <D875ECB5-19A2-4352-BD1B-A3F243C1F782@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<9c9bee94-4bcc-cc48-8d5f-b8c77c9b46cd@oracle.com>
	<3531854f-54ce-3efb-665a-93bb12603c3c@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
	<fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>
	<78be3b64-60c6-e359-aeb1-7bc04d3655be@oracle.com> <4e7e!
	4bf4-d2b7-5e96-e7ef-a6cbf98ddf1e@oracle.com>
	<D875ECB5-19A2-4352-BD1B-A3F243C1F782@oracle.com>
Message-ID: <2bdd84e25c2a4f419459fb727363cf86@DEWDFE13DE11.global.corp.sap>

... and one additional minor remark from my side:
Please also check if the #include <sys/time.h> can be left out from src/java.base/unix/native/libnet/SocketInputStream.c - I don't think it's necessary now as the new "NET_ReadWithTimeout" function does not directly access time APIs.

Other than that I'm fine with the change but I still want to test MSG_NONBLOCK on AIX. So far I've only verified that it builds but MSG_NONBLOCK is not officially documented for AIX. I've only heard from some experts that it "should work" but I'd like to see it in operation. But don't hold back your stuff for that, if worst comes to worse I'll have to do an AIX specific fix.

Best regards
Christoph

> -----Original Message-----
> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris
> Hegarty
> Sent: Dienstag, 13. September 2016 10:48
> To: Vyom Tewari <vyom.tewari at oracle.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Vyom,
> 
> > On 13 Sep 2016, at 04:00, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> >
> > any comment on latest
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html) ?
> 
> I am happy with the way this change turned out. Reviewed.
> 
> Trivially, before you push, just add a space to the four OS specific versions of
> Net_Timeout0, as follows:
> 
>   NET_Timeout0(int s, long timeout, long currentTime)
>                                                        ^^^
> Thanks,
> -Chris.
> 
> > Vyom
> >
> > On Thursday 08 September 2016 03:13 PM, Vyom Tewari wrote:
> >>
> >> On Thursday 08 September 2016 02:50 PM, Langer, Christoph wrote:
> >>> Hi Vyom,
> >>>
> >>> this looks good.
> >>>
> >>> Is there any particular reason why NET_ReadWithTimeout should remain in
> SocketInputStream.c and not also move to net_util_md.c? That way you could
> also have a "static long getCurrentTime()" inside net_util_md.c, instead of an
> exported NET_GetCurrentTime().
> >>>
> >> I thought this "NET_ReadWithTimeou" is specific to SocketInputStream so i
> will be good if we put this method to socketinputstream.c.
> >>
> >> In future we will in using the monotonic increasing clock so
> "NET_GetCurrentTime()" will help , Just change the implementation you are
> done.
> >>
> >> Vyom
> >>>
> >>> And no "#include <sys/time.h>" would be needed in SocketInputStream.c -
> maybe not even now as it is.
> >>>
> >>> Best regards
> >>> Christoph
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Vyom Tewari [
> >>>> mailto:vyom.tewari at oracle.com
> >>>> ]
> >>>> Sent: Donnerstag, 8. September 2016 05:20
> >>>> To: Langer, Christoph
> >>>> <christoph.langer at sap.com>
> >>>>
> >>>> Cc:
> >>>> net-dev at openjdk.java.net
> >>>>
> >>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
> with
> >>>> soTimeout set
> >>>>
> >>>> Hi All,
> >>>>
> >>>> Please find the latest
> >>>> webrev(
> >>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html
> >>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>
> >>>> ).
> >>>>
> >>>> I fixed the AIX flag issue and move some come common code to
> >>>> "net_util_md.c" file.
> >>>>
> >>>> Thanks,
> >>>> Vyom
> >>>>
> >>>> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
> >>>>
> >>>>> Hi Vyom,
> >>>>>
> >>>>> ok, thanks. I have one addition to my proposal: I don't think there's a
> need for
> >>>>>
> >>>> a global NET_GetCurrentTime function. This one should probably be a
> static
> >>>> function inside net_util_md.c (static long getCurrentTime()).
> >>>>
> >>>>> Best
> >>>>> Christoph
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Vyom Tewari [
> >>>>>> mailto:vyom.tewari at oracle.com
> >>>>>> ]
> >>>>>> Sent: Mittwoch, 7. September 2016 18:31
> >>>>>> To: Langer, Christoph
> >>>>>> <christoph.langer at sap.com>
> >>>>>>
> >>>>>> Cc:
> >>>>>> net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
> >>>>>>
> >>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang
> even
> >>>>>>
> >>>> with
> >>>>
> >>>>>> soTimeout set
> >>>>>>
> >>>>>> Hi Chris,
> >>>>>>
> >>>>>> Sorry I was mostly focusing on our test  failure first, i will check
> >>>>>> your suggestions.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Vyom
> >>>>>>
> >>>>>>
> >>>>>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
> >>>>>>
> >>>>>>> Hi Vyom,
> >>>>>>>
> >>>>>>> did you have a look at my suggestions regarding AIX and refactoring? I
> >>>>>>>
> >>>> can't
> >>>>
> >>>>>> find none of it in the new webrev nor did you comment on it.
> >>>>>>
> >>>>>>> Best regards
> >>>>>>> Christoph
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: net-dev [
> >>>>>>>> mailto:net-dev-bounces at openjdk.java.net
> >>>>>>>> ] On Behalf Of
> >>>>>>>>
> >>>>>> Vyom
> >>>>>>
> >>>>>>>> Tewari
> >>>>>>>> Sent: Mittwoch, 7. September 2016 17:10
> >>>>>>>> To: Chris Hegarty
> >>>>>>>> <chris.hegarty at oracle.com>
> >>>>>>>>
> >>>>>>>> Cc:
> >>>>>>>> net-dev at openjdk.java.net
> >>>>>>>>
> >>>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang
> even
> >>>>>>>>
> >>>>>> with
> >>>>>>
> >>>>>>>> soTimeout set
> >>>>>>>>
> >>>>>>>> Hi All,
> >>>>>>>>
> >>>>>>>> Please find the latest
> >>>>>>>>
> >>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
> >>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>
> >>>> ).
> >>>>
> >>>>>>>> there were some test failures in JPRT and Chris also pointed the
> same
> >>>>>>>> issue in modified code. Now with latest code JPRT is clean.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Vyom
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
> >>>>>>>>
> >>>>>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Chris,
> >>>>>>>>>>
> >>>>>>>>>> Please find the latest
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
> >>>>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>
> >>>>>> ). I
> >>>>>>
> >>>>>>>>>> did some code refactoring, JPRT is in progress.
> >>>>>>>>>>
> >>>>>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
> >>>>>>>>> have an additional comment.
> >>>>>>>>>
> >>>>>>>>> If NET_ReadWithTimeout returns -1 because
> >>>>>>>>>
> >>>>>> NET_TimeoutWithCurrentTime
> >>>>>>
> >>>>>>>>> returns <= 0, then a JNI pending exception will be set. So the code
> >>>>>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -
> 1,
> >>>>>>>>> immediately rather than continuing and possibly trying to set
> another
> >>>>>>>>> JNI pending exception.
> >>>>>>>>>
> >>>>>>>>> One option is to check the return value from
> NET_ReadWithTimeout and
> >>>>>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
> >>>>>>>>> the setting of JNI pending exceptions in one place, towards the end
> >>>>>>>>> of Java_java_net_SocketInputStream_socketRead0, for example
> EBADF
> >>>>>>>>>
> >>>> is
> >>>>
> >>>>>>>>> handled in two places.
> >>>>>>>>>
> >>>>>>>>> -Chris.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I need help from some one to build and test latest changes on AIX,
> may
> >>>>>>>>>> be Christoph can help.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Vyom
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Vyom,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari
> <vyom.tewari at oracle.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please find the latest
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
> >>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>
> >>>> ).
> >>>>
> >>>>>>>>>>>> I
> >>>>>>>>>>>> have incorporated the review comments.
> >>>>>>>>>>>>
> >>>>>>>>>>> Your changes completely avoid NET_Timeout, which is quite
> complex
> >>>>>>>>>>>
> >>>> on
> >>>>
> >>>>>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use
> the
> >>>>>>>>>>> async close mechanism to signal/interrupt a thread blocked in a
> poll /
> >>>>>>>>>>> select ). Also, select is used on Mac, which will use poll after your
> >>>>>>>>>>> changes ( I do remember that there was a bug in poll on Mac
> around
> >>>>>>>>>>> the time of the original Mac port ).
> >>>>>>>>>>>
> >>>>>>>>>>> Would is be better, rather than replicating the logic in
> NET_Timeout,
> >>>>>>>>>>> to have a version that supports passing a function pointer, to run
> if
> >>>>>>>>>>> the poll/select returns before the timeout? Just an idea.
> >>>>>>>>>>>
> >>>>>>>>>>> -Chris.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Vyom
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> if the desire is to avoid making double calls on gettimeofday
> in the
> >>>>>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than
> are
> >>>>>>>>>>>>> already done.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> then consider a modification to NET_Timeout and create a
> version
> >>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
> >>>>>>>>>>>>>>
> >>>> timeval *
> >>>>
> >>>>>>>>>>>>>> current_time)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
> >>>>>>>>>>>>>>
> >>>> timeval *
> >>>>
> >>>>>>>>>>>>>> current_time) {
> >>>>>>>>>>>>>>       int result;
> >>>>>>>>>>>>>>       struct timeval t;
> >>>>>>>>>>>>>>       long prevtime, newtime;
> >>>>>>>>>>>>>>       struct pollfd pfd;
> >>>>>>>>>>>>>>       pfd.fd = s;
> >>>>>>>>>>>>>>       pfd.events = POLLIN;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>       if (timeout > 0) {
> >>>>>>>>>>>>>>           prevtime = (current_time->tv_sec * 1000)  +
> >>>>>>>>>>>>>> current_time->tv_usec / 1000;
> >>>>>>>>>>>>>>       }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>       for(;;) {
> >>>>>>>>>>>>>>           result = poll(&pfd, 1, timeout);
> >>>>>>>>>>>>>>           if (result < 0 && errno == EINTR) {
> >>>>>>>>>>>>>>               if (timeout > 0) {
> >>>>>>>>>>>>>>                   gettimeofday(&t, NULL);
> >>>>>>>>>>>>>>                   newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
> >>>>>>>>>>>>>>                   timeout -= newtime - prevtime;
> >>>>>>>>>>>>>>                   if (timeout <= 0)
> >>>>>>>>>>>>>>                       return 0;
> >>>>>>>>>>>>>>                   prevtime = newtime;
> >>>>>>>>>>>>>>               }
> >>>>>>>>>>>>>>           } else {
> >>>>>>>>>>>>>>               return result;
> >>>>>>>>>>>>>>           }
> >>>>>>>>>>>>>>       }
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> the NET_ReadWithTimeout is modified with.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>      while (timeout > 0) {
> >>>>>>>>>>>>>>           result = NET_TimeoutWithCurrentTime(fd, timeout,
> &t);
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> in any case there is the potential for multiple invocation of
> >>>>>>>>>>>>>> gettimeofday due to a need to make
> >>>>>>>>>>>>>> poll restartable,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, and that is fine. Just no more than is already there.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> and adjust the originally specified timeout
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> accordingly, and for the edge case
> >>>>>>>>>>>>>> after the non blocking read.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> After an initial skim, your suggestion seems reasonable.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Chris.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> regards
> >>>>>>>>>>>>>> Mark
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Vyom,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>>>>>>>>>>>>> There is some concern about the potential performance
> effect,
> >>>>>>>>>>>>>>>
> >>>> etc,
> >>>>
> >>>>>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse
> of
> >>>>>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It
> seems that
> >>>>>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT
> reuse
> >>>>>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible
> operation.
> >>>>>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
> >>>>>>>>>>>>>>> execute. Rather than effectively two loops conditioned on
> the
> >>>>>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
> >>>>>>>>>>>>>>> it seems worth considering / evaluating.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Chris.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> hi Dimitry,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
> >>>>>>>>>>>>>>>> increasing
> >>>>>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
> >>>>>>>>>>>>>>>> code("NET_Timeout") uses
> >>>>>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the
> existing
> >>>>>>>>>>>>>>>> code.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff
> >>>>>>>>>>>>>>>>
> >>>> wrote:
> >>>>
> >>>>>>>>>>>>>>>>> Vyom,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Did you consider to use select() to calculate timeout
> instead of
> >>>>>>>>>>>>>>>>> gettimeofday ?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> gettimeofday is affected by system time changes, so
> running
> >>>>>>>>>>>>>>>>>
> >>>> ntpd
> >>>>
> >>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
> >>>>>>>>>>>>>>>>> expensive
> >>>>>>>>>>>>>>>>> syscall.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -Dmitry
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> please find the updated
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>
> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
> >>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>
> >>>> ).
> >>>>
> >>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>> incorporated the review comments.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard
> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>>>>>>>      perhaps there is an opportunity to do  some
> refactoring
> >>>>>>>>>>>>>>>>>>> here (...
> >>>>>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> along the lines
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> if (timeout) {
> >>>>>>>>>>>>>>>>>>>        nread =  NET_ReadWithTimeout(...);
> >>>>>>>>>>>>>>>>>>> } else {
> >>>>>>>>>>>>>>>>>>>         nread = NET_Read(...);
> >>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
> >>>>>>>>>>>>>>>>>>> restructuring of
> >>>>>>>>>>>>>>>>>>> your goto loop
> >>>>>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd,
> _timeout);
> >>>>>>>>>>>>>>>>>>>              if (nread <= 0) {
> >>>>>>>>>>>>>>>>>>>                  if (nread == 0) {
> >>>>>>>>>>>>>>>>>>>                      JNU_ThrowByName(env,
> JNU_JAVANETPKG
> >>>>>>>>>>>>>>>>>>> "SocketTimeoutException",
> >>>>>>>>>>>>>>>>>>>                                  "Read timed out");
> >>>>>>>>>>>>>>>>>>>                  } else if (nread == -1) {
> >>>>>>>>>>>>>>>>>>>                      if (errno == EBADF) {
> >>>>>>>>>>>>>>>>>>>                           JNU_ThrowByName(env,
> JNU_JAVANETPKG
> >>>>>>>>>>>>>>>>>>> "SocketException", "Socket closed");
> >>>>>>>>>>>>>>>>>>>                      } else if (errno == ENOMEM) {
> >>>>>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
> >>>>>>>>>>>>>>>>>>> "NET_Timeout
> >>>>>>>>>>>>>>>>>>> native heap allocation failed");
> >>>>>>>>>>>>>>>>>>>                      } else {
> >>>>>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
> >>>>>>>>>>>>>>>>>>>                              (env, JNU_JAVANETPKG
> >>>>>>>>>>>>>>>>>>> "SocketException",
> >>>>>>>>>>>>>>>>>>> "select/poll failed");
> >>>>>>>>>>>>>>>>>>>                      }
> >>>>>>>>>>>>>>>>>>>                  }
> >>>>>>>>>>>>>>>>>>>                    // release buffer in main call flow
> >>>>>>>>>>>>>>>>>>> //              if (bufP != BUF) {
> >>>>>>>>>>>>>>>>>>> //                  free(bufP);
> >>>>>>>>>>>>>>>>>>> //             }
> >>>>>>>>>>>>>>>>>>>                 nread = -1;
> >>>>>>>>>>>>>>>>>>>                 break;
> >>>>>>>>>>>>>>>>>>>              } else {
> >>>>>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
> >>>>>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
> >>>>>>>>>>>>>>>>>>> EWOULDBLOCK))) {
> >>>>>>>>>>>>>>>>>>>                  gettimeofday(&t, NULL);
> >>>>>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
> >>>>>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
> >>>>>>>>>>>>>>>>>>> if(_timeout > 0){
> >>>>>>>>>>>>>>>>>>> prevtime = newtime;
> >>>>>>>>>>>>>>>>>>>                      }
> >>>>>>>>>>>>>>>>>>> } else { break; } } } return nread;
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> e&oe
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> regards
> >>>>>>>>>>>>>>>>>>> Mark
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> gentle reminder, please review the below code
> change.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari
> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Bug         :
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> webrev    :
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> >>>>>>>>
> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >>>>>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs
> even
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>> with
> >>>>>>
> >>>>>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
> >>>>>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0
> assumes
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>> that
> >>>>>>
> >>>>>>>>>>>>>>>>>>>>> read()
> >>>>>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is
> possible.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man
> page
> >>>>>>>>>>>>>>>>>>>>>
> >>>> for
> >>>>
> >>>>>>>>>>>>>>>>>>>>> select
> >>>>>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux,
> >>>>>>>>>>>>>>>>>>>>>
> >>>> select()
> >>>>
> >>>>>>>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading",
> >>>>>>>>>>>>>>>>>>>>>
> >>>> while
> >>>>
> >>>>>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>> example
> >>>>>>
> >>>>>>>>>>>>>>>>>>>>> happen
> >>>>>>>>>>>>>>>>>>>>> when data has arrived but upon examination has
> wrong
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> checksum
> >>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> and is
> >>>>>>>>>>>>>>>>>>>>> discarded.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Vyom
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>
> >


From vyom.tewari at oracle.com  Tue Sep 13 12:57:59 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 13 Sep 2016 18:27:59 +0530
Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
	soTimeout set
In-Reply-To: <D875ECB5-19A2-4352-BD1B-A3F243C1F782@oracle.com>
References: <212552c5-b8b0-bcd0-fdfb-aa8f1f231ff9@oracle.com>
	<2ced443e-8a42-148f-3cc9-513f46862efa@oracle.com>
	<26500eb6-ab58-bb40-cfa8-fa6876f9c430@oracle.com>
	<30294b5f-56fa-b1d2-9c2c-166e4bfd26ae@oracle.com>
	<2d2988c1-c4f9-9f0b-e9af-a20820ab3219@oracle.com>
	<71f665aa-8952-8d59-1a81-af996713e301@oracle.com>
	<ca1bbe40-ebe2-c85c-4769-08ab1e19b160@oracle.com>
	<631A4019-20BD-44FE-83B7-9FD93B7350AF@oracle.com>
	<db86cc59-905d-e908-9180-8fdec07704f5@oracle.com>
	<85583067-4549-3131-3714-9fb232ccd3de@oracle.com>
	<c9ff4b9a-6c19-5e46-edfc-314b42963767@oracle.com>
	<2c4d0ee046524f749e565e47f520d6d9@DEWDFE13DE11.global.corp.sap>
	<008dbba8-ac20-6f31-0e5f-3e23518e4f98@oracle.com>
	<be1949e4fdc14c41b352c8564f46a992@DEWDFE13DE11.global.corp.sap>
	<57D0D8D5.5090809@oracle.com>
	<fafbe8923c144313b6aad943ec0f1e1d@DEWDFE13DE11.global.corp.sap>
	<78be3b64-60c6-e359-aeb1-7bc04d3655be@oracle.com>
	<4e7e4bf4-d2b7-5e96-e7ef-a6cbf98ddf1e@oracle.com>
	<D875ECB5-19A2-4352-BD1B-A3F243C1F782@oracle.com>
Message-ID: <7d71ad7f-2493-b09d-76cf-cfab3c8fbcbf@oracle.com>

pushed.

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd

Vyom


On Tuesday 13 September 2016 02:17 PM, Chris Hegarty wrote:
> Vyom,
>
>> On 13 Sep 2016, at 04:00, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>
>> any comment on latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html) ?
> I am happy with the way this change turned out. Reviewed.
>
> Trivially, before you push, just add a space to the four OS specific versions of
> Net_Timeout0, as follows:
>
>    NET_Timeout0(int s, long timeout, long currentTime)
>                                                         ^^^
> Thanks,
> -Chris.
>
>> Vyom
>>
>> On Thursday 08 September 2016 03:13 PM, Vyom Tewari wrote:
>>> On Thursday 08 September 2016 02:50 PM, Langer, Christoph wrote:
>>>> Hi Vyom,
>>>>
>>>> this looks good.
>>>>
>>>> Is there any particular reason why NET_ReadWithTimeout should remain in SocketInputStream.c and not also move to net_util_md.c? That way you could also have a "static long getCurrentTime()" inside net_util_md.c, instead of an exported NET_GetCurrentTime().
>>>>
>>> I thought this "NET_ReadWithTimeou" is specific to SocketInputStream so i will be good if we put this method to socketinputstream.c.
>>>
>>> In future we will in using the monotonic increasing clock so "NET_GetCurrentTime()" will help , Just change the implementation you are done.
>>>
>>> Vyom
>>>>   
>>>> And no "#include <sys/time.h>" would be needed in SocketInputStream.c - maybe not even now as it is.
>>>>
>>>> Best regards
>>>> Christoph
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Vyom Tewari [
>>>>> mailto:vyom.tewari at oracle.com
>>>>> ]
>>>>> Sent: Donnerstag, 8. September 2016 05:20
>>>>> To: Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>>
>>>>> Cc:
>>>>> net-dev at openjdk.java.net
>>>>>
>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
>>>>> soTimeout set
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Please find the latest
>>>>> webrev(
>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>
>>>>> ).
>>>>>
>>>>> I fixed the AIX flag issue and move some come common code to
>>>>> "net_util_md.c" file.
>>>>>
>>>>> Thanks,
>>>>> Vyom
>>>>>
>>>>> On 9/8/2016 12:32 PM, Langer, Christoph wrote:
>>>>>
>>>>>> Hi Vyom,
>>>>>>
>>>>>> ok, thanks. I have one addition to my proposal: I don't think there's a need for
>>>>>>
>>>>> a global NET_GetCurrentTime function. This one should probably be a static
>>>>> function inside net_util_md.c (static long getCurrentTime()).
>>>>>
>>>>>> Best
>>>>>> Christoph
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Vyom Tewari [
>>>>>>> mailto:vyom.tewari at oracle.com
>>>>>>> ]
>>>>>>> Sent: Mittwoch, 7. September 2016 18:31
>>>>>>> To: Langer, Christoph
>>>>>>> <christoph.langer at sap.com>
>>>>>>>
>>>>>>> Cc:
>>>>>>> net-dev at openjdk.java.net; Chris Hegarty <chris.hegarty at oracle.com>
>>>>>>>
>>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>>>>>>
>>>>> with
>>>>>
>>>>>>> soTimeout set
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> Sorry I was mostly focusing on our test  failure first, i will check
>>>>>>> your suggestions.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday 07 September 2016 08:44 PM, Langer, Christoph wrote:
>>>>>>>
>>>>>>>> Hi Vyom,
>>>>>>>>
>>>>>>>> did you have a look at my suggestions regarding AIX and refactoring? I
>>>>>>>>
>>>>> can't
>>>>>
>>>>>>> find none of it in the new webrev nor did you comment on it.
>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Christoph
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: net-dev [
>>>>>>>>> mailto:net-dev-bounces at openjdk.java.net
>>>>>>>>> ] On Behalf Of
>>>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>>> Tewari
>>>>>>>>> Sent: Mittwoch, 7. September 2016 17:10
>>>>>>>>> To: Chris Hegarty
>>>>>>>>> <chris.hegarty at oracle.com>
>>>>>>>>>
>>>>>>>>> Cc:
>>>>>>>>> net-dev at openjdk.java.net
>>>>>>>>>
>>>>>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even
>>>>>>>>>
>>>>>>> with
>>>>>>>
>>>>>>>>> soTimeout set
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please find the latest
>>>>>>>>>
>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.4/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.4/index.html>
>>>>> ).
>>>>>
>>>>>>>>> there were some test failures in JPRT and Chris also pointed the same
>>>>>>>>> issue in modified code. Now with latest code JPRT is clean.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Vyom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote:
>>>>>>>>>
>>>>>>>>>> On 07/09/16 07:45, Vyom Tewari wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> Please find the latest
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.3/index.html>
>>>>>>> ). I
>>>>>>>
>>>>>>>>>>> did some code refactoring, JPRT is in progress.
>>>>>>>>>>>
>>>>>>>>>> In terms of NET_Timeout**, I'm happy with this version, but I
>>>>>>>>>> have an additional comment.
>>>>>>>>>>
>>>>>>>>>> If NET_ReadWithTimeout returns -1 because
>>>>>>>>>>
>>>>>>> NET_TimeoutWithCurrentTime
>>>>>>>
>>>>>>>>>> returns <= 0, then a JNI pending exception will be set. So the code
>>>>>>>>>> calling NET_ReadWithTimeout should, a) free bufP, and b) return -1,
>>>>>>>>>> immediately rather than continuing and possibly trying to set another
>>>>>>>>>> JNI pending exception.
>>>>>>>>>>
>>>>>>>>>> One option is to check the return value from NET_ReadWithTimeout and
>>>>>>>>>> also (*env)->ExceptionCheck(env). Another is to possibly consolidate
>>>>>>>>>> the setting of JNI pending exceptions in one place, towards the end
>>>>>>>>>> of Java_java_net_SocketInputStream_socketRead0, for example EBADF
>>>>>>>>>>
>>>>> is
>>>>>
>>>>>>>>>> handled in two places.
>>>>>>>>>>
>>>>>>>>>> -Chris.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I need help from some one to build and test latest changes on AIX, may
>>>>>>>>>>> be Christoph can help.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Vyom
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tewari at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please find the latest
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>
>>>>> ).
>>>>>
>>>>>>>>>>>>> I
>>>>>>>>>>>>> have incorporated the review comments.
>>>>>>>>>>>>>
>>>>>>>>>>>> Your changes completely avoid NET_Timeout, which is quite complex
>>>>>>>>>>>>
>>>>> on
>>>>>
>>>>>>>>>>>> Linux, Mac, and AIX, for various reasons. ( NET_Timeout will use the
>>>>>>>>>>>> async close mechanism to signal/interrupt a thread blocked in a poll /
>>>>>>>>>>>> select ). Also, select is used on Mac, which will use poll after your
>>>>>>>>>>>> changes ( I do remember that there was a bug in poll on Mac around
>>>>>>>>>>>> the time of the original Mac port ).
>>>>>>>>>>>>
>>>>>>>>>>>> Would is be better, rather than replicating the logic in NET_Timeout,
>>>>>>>>>>>> to have a version that supports passing a function pointer, to run if
>>>>>>>>>>>> the poll/select returns before the timeout? Just an idea.
>>>>>>>>>>>>
>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05/09/16 15:37, Mark Sheppard wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> if the desire is to avoid making double calls on gettimeofday in the
>>>>>>>>>>>>>>> NET_ReadWithTimeout's while loop for its main call flow,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, the desire is to make no more calls to gettimeofday, than are
>>>>>>>>>>>>>> already done.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> then consider a modification to NET_Timeout and create a version
>>>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>>>>>>>>>>>>>>>
>>>>> timeval *
>>>>>
>>>>>>>>>>>>>>> current_time)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int NET_TimeoutWithCurrentTime(int s, long timeout, stuct
>>>>>>>>>>>>>>>
>>>>> timeval *
>>>>>
>>>>>>>>>>>>>>> current_time) {
>>>>>>>>>>>>>>>        int result;
>>>>>>>>>>>>>>>        struct timeval t;
>>>>>>>>>>>>>>>        long prevtime, newtime;
>>>>>>>>>>>>>>>        struct pollfd pfd;
>>>>>>>>>>>>>>>        pfd.fd = s;
>>>>>>>>>>>>>>>        pfd.events = POLLIN;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        if (timeout > 0) {
>>>>>>>>>>>>>>>            prevtime = (current_time->tv_sec * 1000)  +
>>>>>>>>>>>>>>> current_time->tv_usec / 1000;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        for(;;) {
>>>>>>>>>>>>>>>            result = poll(&pfd, 1, timeout);
>>>>>>>>>>>>>>>            if (result < 0 && errno == EINTR) {
>>>>>>>>>>>>>>>                if (timeout > 0) {
>>>>>>>>>>>>>>>                    gettimeofday(&t, NULL);
>>>>>>>>>>>>>>>                    newtime = (t.tv_sec * 1000)  + t.tv_usec /1000;
>>>>>>>>>>>>>>>                    timeout -= newtime - prevtime;
>>>>>>>>>>>>>>>                    if (timeout <= 0)
>>>>>>>>>>>>>>>                        return 0;
>>>>>>>>>>>>>>>                    prevtime = newtime;
>>>>>>>>>>>>>>>                }
>>>>>>>>>>>>>>>            } else {
>>>>>>>>>>>>>>>                return result;
>>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the NET_ReadWithTimeout is modified with.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       while (timeout > 0) {
>>>>>>>>>>>>>>>            result = NET_TimeoutWithCurrentTime(fd, timeout, &t);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> in any case there is the potential for multiple invocation of
>>>>>>>>>>>>>>> gettimeofday due to a need to make
>>>>>>>>>>>>>>> poll restartable,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, and that is fine. Just no more than is already there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and adjust the originally specified timeout
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> accordingly, and for the edge case
>>>>>>>>>>>>>>> after the non blocking read.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After an initial skim, your suggestion seems reasonable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 05/09/2016 12:02, Chris Hegarty wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>>>>>>>>>>>>> There is some concern about the potential performance effect,
>>>>>>>>>>>>>>>>
>>>>> etc,
>>>>>
>>>>>>>>>>>>>>>> of gettimeofday, maybe there is a way out of this. The reuse of
>>>>>>>>>>>>>>>> NET_Timeout is good, but it also calls gettimeofday. It seems that
>>>>>>>>>>>>>>>> a specific NET_ReadWithTimeout could be written to NOT reuse
>>>>>>>>>>>>>>>> NET_Timeout, but effectively inline its interruptible operation.
>>>>>>>>>>>>>>>> Or write a variant of NET_Timeout that takes a function to
>>>>>>>>>>>>>>>> execute. Rather than effectively two loops conditioned on the
>>>>>>>>>>>>>>>> timeout.  Disclaimer: I have not actually tried to do this, but
>>>>>>>>>>>>>>>> it seems worth considering / evaluating.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 02/09/16 04:39, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hi Dimitry,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks for review, I did consider to use  a monotonically
>>>>>>>>>>>>>>>>> increasing
>>>>>>>>>>>>>>>>> clock like "clock_gettime" but  existing nearby
>>>>>>>>>>>>>>>>> code("NET_Timeout") uses
>>>>>>>>>>>>>>>>> "gettimeofday"  so i choose to be consistent with the existing
>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff
>>>>>>>>>>>>>>>>>
>>>>> wrote:
>>>>>
>>>>>>>>>>>>>>>>>> Vyom,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Did you consider to use select() to calculate timeout instead of
>>>>>>>>>>>>>>>>>> gettimeofday ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gettimeofday is affected by system time changes, so running
>>>>>>>>>>>>>>>>>>
>>>>> ntpd
>>>>>
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>> cause unpredictable behavior of this code. Also it's rather
>>>>>>>>>>>>>>>>>> expensive
>>>>>>>>>>>>>>>>>> syscall.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2016-09-01 19:03, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> please find the updated
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.1/index.html>
>>>>> ).
>>>>>
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>> incorporated the review comments.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>>>       perhaps there is an opportunity to do  some refactoring
>>>>>>>>>>>>>>>>>>>> here (...
>>>>>>>>>>>>>>>>>>>> for me a "goto " carries a code smell! )
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> along the lines
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> if (timeout) {
>>>>>>>>>>>>>>>>>>>>         nread =  NET_ReadWithTimeout(...);
>>>>>>>>>>>>>>>>>>>> } else {
>>>>>>>>>>>>>>>>>>>>          nread = NET_Read(...);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> the NET_ReadWithTimeout (...) function will contain a
>>>>>>>>>>>>>>>>>>>> restructuring of
>>>>>>>>>>>>>>>>>>>> your goto loop
>>>>>>>>>>>>>>>>>>>> while (_timeout > 0) { nread = NET_Timeout(fd, _timeout);
>>>>>>>>>>>>>>>>>>>>               if (nread <= 0) {
>>>>>>>>>>>>>>>>>>>>                   if (nread == 0) {
>>>>>>>>>>>>>>>>>>>>                       JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>>>> "SocketTimeoutException",
>>>>>>>>>>>>>>>>>>>>                                   "Read timed out");
>>>>>>>>>>>>>>>>>>>>                   } else if (nread == -1) {
>>>>>>>>>>>>>>>>>>>>                       if (errno == EBADF) {
>>>>>>>>>>>>>>>>>>>>                            JNU_ThrowByName(env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>>>> "SocketException", "Socket closed");
>>>>>>>>>>>>>>>>>>>>                       } else if (errno == ENOMEM) {
>>>>>>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env,
>>>>>>>>>>>>>>>>>>>> "NET_Timeout
>>>>>>>>>>>>>>>>>>>> native heap allocation failed");
>>>>>>>>>>>>>>>>>>>>                       } else {
>>>>>>>>>>>>>>>>>>>> JNU_ThrowByNameWithMessageAndLastError
>>>>>>>>>>>>>>>>>>>>                               (env, JNU_JAVANETPKG
>>>>>>>>>>>>>>>>>>>> "SocketException",
>>>>>>>>>>>>>>>>>>>> "select/poll failed");
>>>>>>>>>>>>>>>>>>>>                       }
>>>>>>>>>>>>>>>>>>>>                   }
>>>>>>>>>>>>>>>>>>>>                     // release buffer in main call flow
>>>>>>>>>>>>>>>>>>>> //              if (bufP != BUF) {
>>>>>>>>>>>>>>>>>>>> //                  free(bufP);
>>>>>>>>>>>>>>>>>>>> //             }
>>>>>>>>>>>>>>>>>>>>                  nread = -1;
>>>>>>>>>>>>>>>>>>>>                  break;
>>>>>>>>>>>>>>>>>>>>               } else {
>>>>>>>>>>>>>>>>>>>> nread = NET_NonBlockingRead(fd, bufP, len);
>>>>>>>>>>>>>>>>>>>> if (nread == -1 && ((errno == EAGAIN) || (errno ==
>>>>>>>>>>>>>>>>>>>> EWOULDBLOCK))) {
>>>>>>>>>>>>>>>>>>>>                   gettimeofday(&t, NULL);
>>>>>>>>>>>>>>>>>>>> newtime = t.tv_sec * 1000 + t.tv_usec / 1000;
>>>>>>>>>>>>>>>>>>>> _timeout -= newtime - prevtime;
>>>>>>>>>>>>>>>>>>>> if(_timeout > 0){
>>>>>>>>>>>>>>>>>>>> prevtime = newtime;
>>>>>>>>>>>>>>>>>>>>                       }
>>>>>>>>>>>>>>>>>>>> } else { break; } } } return nread;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> e&oe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 29/08/2016 10:58, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> gentle reminder, please review the below code change.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Please review the code changes for below issue.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Bug         :
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075484
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> webrev    :
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>>>>>>>>>>>>>>>>>>> This issue is SocketInputStream.socketread0() hangs even
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> with
>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> "soTimeout" set.the implementation of
>>>>>>>>>>>>>>>>>>>>>> Java_java_net_SocketInputStream_socketRead0 assumes
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> that
>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> read()
>>>>>>>>>>>>>>>>>>>>>> won't block after poll() reports that a read is possible.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This assumption does not hold, as noted on the man page
>>>>>>>>>>>>>>>>>>>>>>
>>>>> for
>>>>>
>>>>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>>>>> (referenced by the man page for poll): Under Linux,
>>>>>>>>>>>>>>>>>>>>>>
>>>>> select()
>>>>>
>>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>> report a socket file descriptor as "ready for reading",
>>>>>>>>>>>>>>>>>>>>>>
>>>>> while
>>>>>
>>>>>>>>>>>>>>>>>>>>>> nevertheless a subsequent read blocks. This could for
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> example
>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>>>>>>> when data has arrived but upon examination has wrong
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> checksum
>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>>>>> discarded.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Vyom
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>


From chris.hegarty at oracle.com  Wed Sep 14 10:43:56 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Sep 2016 11:43:56 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
Message-ID: <f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>

Vyom,

On 11/09/16 08:01, Vyom Tewari wrote:
> Hi All,
>
> Please review the below code change.
>
> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>
> Webrev  :
> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>
> This change override the "get/setReuseAddress"  for MulticaseSocket and
> will abstract with both reuse attributes(SO_REUSEADDR & SO_REUSEPORT).

This issue arises since the changes for 6432031 "Add support for 
SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
the available. So setting setReuseAddress(false) alone is no longer
sufficient to disable address/port reuse, one must also set
SO_REUSEPORT to false.

I would be really nervous about changing set/getReuseAddress, without
at least updating the javadoc to indicate that it is now, for MS,
operating on two socket options.  Although, I do have sympathy
here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
dealing with multicasting.

An alternative, maybe; Since the MS constructors document that
SO_REUSEPORT will be set, where available, maybe a javadoc note
on the set/getReuseAddress methods would be sufficient, that
indicates that StandardSocketOptions#SO_REUSEPORT may also need
to be set to have the desired effect?

If so, then code would have to:

     setReuseAddress(false);

     if (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
         this.setOption(StandardSocketOptions.SO_REUSEPORT, false);

   , but at least it is explicit.

Q: not all MS constructors document that SO_REUSEPORT is set, but
they should, right? This seems to have slipped past during 6432031 [1].

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-6432031

From mark.sheppard at oracle.com  Wed Sep 14 12:23:31 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 14 Sep 2016 13:23:31 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
Message-ID: <cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>


Hi Chris,
     so are you accepting that it is correct to add the overridden 
methods in MulticastSocket and that these need
appropriate javadoc ?

or are you advocating pushing the handing of the SO_REUSEPORT into the 
base DatagramSocket class ?

It is not clear how your code changes fit in the proposed fix i.e. the 
explicit setting of the option to false?

With the current proposed changes then I think it would be sufficient to 
invoke setReuseAddress(true) in MulticastSocket constructors
rather than

         // Enable SO_REUSEADDR before binding
         setReuseAddress 
<https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);

         // Enable SO_REUSEPORT if supported before binding
         *if*  (supportedOptions 
<https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains 
<https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions 
<https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
<https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) {
             *this*.setOption 
<https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions 
<https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
<https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,*true*);
         }


as the overridden setReuseAddress takes care of SO_REUSEPORT

regards
Mark

On 14/09/2016 11:43, Chris Hegarty wrote:
> Vyom,
>
> On 11/09/16 08:01, Vyom Tewari wrote:
>> Hi All,
>>
>> Please review the below code change.
>>
>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>
>> Webrev  :
>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>
>> This change override the "get/setReuseAddress"  for MulticaseSocket and
>> will abstract with both reuse attributes(SO_REUSEADDR & SO_REUSEPORT).
>
> This issue arises since the changes for 6432031 "Add support for 
> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
> the available. So setting setReuseAddress(false) alone is no longer
> sufficient to disable address/port reuse, one must also set
> SO_REUSEPORT to false.
>
> I would be really nervous about changing set/getReuseAddress, without
> at least updating the javadoc to indicate that it is now, for MS,
> operating on two socket options.  Although, I do have sympathy
> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
> dealing with multicasting.
>
> An alternative, maybe; Since the MS constructors document that
> SO_REUSEPORT will be set, where available, maybe a javadoc note
> on the set/getReuseAddress methods would be sufficient, that
> indicates that StandardSocketOptions#SO_REUSEPORT may also need
> to be set to have the desired effect?
>
> If so, then code would have to:
>
>     setReuseAddress(false);
>
>     if (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>         this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>
>   , but at least it is explicit.
>
> Q: not all MS constructors document that SO_REUSEPORT is set, but
> they should, right? This seems to have slipped past during 6432031 [1].
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6432031

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160914/d9be1941/attachment-0001.html>

From chris.hegarty at oracle.com  Wed Sep 14 12:34:44 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Sep 2016 13:34:44 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
Message-ID: <06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>

Mark,

On 14/09/16 13:23, Mark Sheppard wrote:
>
> Hi Chris,
>     so are you accepting that it is correct to add the overridden
> methods in MulticastSocket and that these need
> appropriate javadoc ?

I think we need these, but they should just call their super
equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
exist solely as a place to locate guidance, or a note, that one
will likely want to set SO_REUSEPORT too.

> or are you advocating pushing the handing of the SO_REUSEPORT into the
> base DatagramSocket class ?

It is already there. I am not proposing to change this.

> It is not clear how your code changes fit in the proposed fix i.e. the
> explicit setting of the option to false?

My proposal is an alternative. It is not related to the current
webrev.

> With the current proposed changes then I think it would be sufficient to
> invoke setReuseAddress(true) in MulticastSocket constructors
> rather than
>
>         // Enable SO_REUSEADDR before binding
>         setReuseAddress
> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);
>
>         // Enable SO_REUSEPORT if supported before binding
>         *if* (supportedOptions
> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains
> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions
> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) {
>             *this*.setOption
> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions
> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>, *true*);
>         }
>
>
> as the overridden setReuseAddress takes care of SO_REUSEPORT

Yes, this is what Vyom has proposed, in the webrev.

I would like to explore an alternative, so see what it would look like.

-Chris.


> regards
> Mark
>
> On 14/09/2016 11:43, Chris Hegarty wrote:
>> Vyom,
>>
>> On 11/09/16 08:01, Vyom Tewari wrote:
>>> Hi All,
>>>
>>> Please review the below code change.
>>>
>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>
>>> Webrev  :
>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>>
>>> This change override the "get/setReuseAddress"  for MulticaseSocket and
>>> will abstract with both reuse attributes(SO_REUSEADDR & SO_REUSEPORT).
>>
>> This issue arises since the changes for 6432031 "Add support for
>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>> the available. So setting setReuseAddress(false) alone is no longer
>> sufficient to disable address/port reuse, one must also set
>> SO_REUSEPORT to false.
>>
>> I would be really nervous about changing set/getReuseAddress, without
>> at least updating the javadoc to indicate that it is now, for MS,
>> operating on two socket options.  Although, I do have sympathy
>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>> dealing with multicasting.
>>
>> An alternative, maybe; Since the MS constructors document that
>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>> on the set/getReuseAddress methods would be sufficient, that
>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>> to be set to have the desired effect?
>>
>> If so, then code would have to:
>>
>>     setReuseAddress(false);
>>
>>     if (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>         this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>
>>   , but at least it is explicit.
>>
>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>> they should, right? This seems to have slipped past during 6432031 [1].
>>
>> -Chris.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>

From mark.sheppard at oracle.com  Wed Sep 14 13:22:57 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 14 Sep 2016 14:22:57 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
Message-ID: <1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>


Hi Chris,
      I don't fully understand your objections to the approach taken.
Is there a compatibility issue with the addition of the additional 
methods to MulticastSocket?

I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT 
option, this has to be done explicitly via setOption at this level of 
abstraction.

MulticastSocket is a subclass of DatagramSocket (that in itself is a 
questionable structuring), and as such
has specialized behaviour, and part  of that specialization is the 
setting of  the setting SO_REUSEADDR and SO_REUSEPORT
in its constructors, to enable address reuse semantics, prior to binding 
an address.
As part of that specialization, it would seem appropriate that 
MulticastSocket manipulate the SO_REUSEPORT
option in a consistent way. Adding an overridden setReuseAddress(...) 
method provides that consistency and
encapsulates the specialized behaviour.

Is alternatively proposal to NOT do anything to MulticastSocket, BUT 
document clearly how to handle the failing scenario, that an MulticastSocket
requires both setReuseAddress() and a setOption call to disable 
reuseaddress semantics on an unbound MulticastSocket ?


This then raises the question of why have a convenience method, such as 
setReuseAddress() in the first place, when it can be handled
adequately via the setOption

regards
Mark

On 14/09/2016 13:34, Chris Hegarty wrote:
> Mark,
>
> On 14/09/16 13:23, Mark Sheppard wrote:
>>
>> Hi Chris,
>>     so are you accepting that it is correct to add the overridden
>> methods in MulticastSocket and that these need
>> appropriate javadoc ?
>
> I think we need these, but they should just call their super
> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
> exist solely as a place to locate guidance, or a note, that one
> will likely want to set SO_REUSEPORT too.
>
>> or are you advocating pushing the handing of the SO_REUSEPORT into the
>> base DatagramSocket class ?
>
> It is already there. I am not proposing to change this.
>
>> It is not clear how your code changes fit in the proposed fix i.e. the
>> explicit setting of the option to false?
>
> My proposal is an alternative. It is not related to the current
> webrev.
>
>> With the current proposed changes then I think it would be sufficient to
>> invoke setReuseAddress(true) in MulticastSocket constructors
>> rather than
>>
>>         // Enable SO_REUSEADDR before binding
>>         setReuseAddress
>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*); 
>>
>>
>>         // Enable SO_REUSEPORT if supported before binding
>>         *if* (supportedOptions
>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains 
>>
>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions 
>>
>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>
>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) 
>> {
>>             *this*.setOption
>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions 
>>
>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>
>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>, 
>> *true*);
>>         }
>>
>>
>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>
> Yes, this is what Vyom has proposed, in the webrev.
>
> I would like to explore an alternative, so see what it would look like.
>
> -Chris.
>
>
>> regards
>> Mark
>>
>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>> Vyom,
>>>
>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>> Hi All,
>>>>
>>>> Please review the below code change.
>>>>
>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>
>>>> Webrev  :
>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>>>
>>>> This change override the "get/setReuseAddress"  for MulticaseSocket 
>>>> and
>>>> will abstract with both reuse attributes(SO_REUSEADDR & SO_REUSEPORT).
>>>
>>> This issue arises since the changes for 6432031 "Add support for
>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>> the available. So setting setReuseAddress(false) alone is no longer
>>> sufficient to disable address/port reuse, one must also set
>>> SO_REUSEPORT to false.
>>>
>>> I would be really nervous about changing set/getReuseAddress, without
>>> at least updating the javadoc to indicate that it is now, for MS,
>>> operating on two socket options.  Although, I do have sympathy
>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>> dealing with multicasting.
>>>
>>> An alternative, maybe; Since the MS constructors document that
>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>> on the set/getReuseAddress methods would be sufficient, that
>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>> to be set to have the desired effect?
>>>
>>> If so, then code would have to:
>>>
>>>     setReuseAddress(false);
>>>
>>>     if 
>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>         this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>
>>>   , but at least it is explicit.
>>>
>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>> they should, right? This seems to have slipped past during 6432031 [1].
>>>
>>> -Chris.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>


From chris.hegarty at oracle.com  Wed Sep 14 13:47:15 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Sep 2016 14:47:15 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
Message-ID: <56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>

Mark,

On 14/09/16 14:22, Mark Sheppard wrote:
>
> Hi Chris,
>      I don't fully understand your objections to the approach taken.
> Is there a compatibility issue with the addition of the additional
> methods to MulticastSocket?

The concern is with setReuseAddress performing an operation that
is not clear from the method specification, e.g. from setReuseAddress()

      * Enable/disable the SO_REUSEADDR socket option.

This is no longer accurate. The proposed changes would affect
SO_REUSEPORT too.

> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
> option, this has to be done explicitly via setOption at this level of
> abstraction.

Yes, it is a bit odd, but these are legacy classes. I am not opposed
to adding a new method for this, or something else. I just want to
avoid future issues and confusion when setReuseAddress is called and
then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's
value has changed. setReuseAddress's spec is very clear about what it
does.

> MulticastSocket is a subclass of DatagramSocket (that in itself is a
> questionable structuring), and as such
> has specialized behaviour, and part  of that specialization is the
> setting of  the setting SO_REUSEADDR and SO_REUSEPORT
> in its constructors, to enable address reuse semantics, prior to binding
> an address.

Understood. Of course, the setting of SO_REUSEPORT is new in 9,
hence the problem.

> As part of that specialization, it would seem appropriate that
> MulticastSocket manipulate the SO_REUSEPORT
> option in a consistent way. Adding an overridden setReuseAddress(...)
> method provides that consistency and
> encapsulates the specialized behaviour.

I agree with the abstraction, just not that setReuseAddress should
be used to achieve it. The name and spec of this method is so
tied to SO_REUSEADDR.

> Is alternatively proposal to NOT do anything to MulticastSocket, BUT
> document clearly how to handle the failing scenario, that an
> MulticastSocket
> requires both setReuseAddress() and a setOption call to disable
> reuseaddress semantics on an unbound MulticastSocket ?

That is one option, and the option that I was suggesting as a possible
alternative.

> This then raises the question of why have a convenience method, such as
> setReuseAddress() in the first place, when it can be handled
> adequately via the setOption

We are moving away from these option specific getter and setter
methods, in favor of the more general get/setOption methods, as
the latter are more adaptable.

If setReuseAddress is to operate on more than SO_REUSEADDR, then
its spec should be very clear about this.

-Chris.


> regards
> Mark
>
> On 14/09/2016 13:34, Chris Hegarty wrote:
>> Mark,
>>
>> On 14/09/16 13:23, Mark Sheppard wrote:
>>>
>>> Hi Chris,
>>>     so are you accepting that it is correct to add the overridden
>>> methods in MulticastSocket and that these need
>>> appropriate javadoc ?
>>
>> I think we need these, but they should just call their super
>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
>> exist solely as a place to locate guidance, or a note, that one
>> will likely want to set SO_REUSEPORT too.
>>
>>> or are you advocating pushing the handing of the SO_REUSEPORT into the
>>> base DatagramSocket class ?
>>
>> It is already there. I am not proposing to change this.
>>
>>> It is not clear how your code changes fit in the proposed fix i.e. the
>>> explicit setting of the option to false?
>>
>> My proposal is an alternative. It is not related to the current
>> webrev.
>>
>>> With the current proposed changes then I think it would be sufficient to
>>> invoke setReuseAddress(true) in MulticastSocket constructors
>>> rather than
>>>
>>>         // Enable SO_REUSEADDR before binding
>>>         setReuseAddress
>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);
>>>
>>>
>>>         // Enable SO_REUSEPORT if supported before binding
>>>         *if* (supportedOptions
>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains
>>>
>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions
>>>
>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>
>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>))
>>> {
>>>             *this*.setOption
>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions
>>>
>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>
>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,
>>> *true*);
>>>         }
>>>
>>>
>>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>>
>> Yes, this is what Vyom has proposed, in the webrev.
>>
>> I would like to explore an alternative, so see what it would look like.
>>
>> -Chris.
>>
>>
>>> regards
>>> Mark
>>>
>>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>>> Vyom,
>>>>
>>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the below code change.
>>>>>
>>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>>
>>>>> Webrev  :
>>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>>>>
>>>>> This change override the "get/setReuseAddress"  for MulticaseSocket
>>>>> and
>>>>> will abstract with both reuse attributes(SO_REUSEADDR & SO_REUSEPORT).
>>>>
>>>> This issue arises since the changes for 6432031 "Add support for
>>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>>> the available. So setting setReuseAddress(false) alone is no longer
>>>> sufficient to disable address/port reuse, one must also set
>>>> SO_REUSEPORT to false.
>>>>
>>>> I would be really nervous about changing set/getReuseAddress, without
>>>> at least updating the javadoc to indicate that it is now, for MS,
>>>> operating on two socket options.  Although, I do have sympathy
>>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>>> dealing with multicasting.
>>>>
>>>> An alternative, maybe; Since the MS constructors document that
>>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>>> on the set/getReuseAddress methods would be sufficient, that
>>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>>> to be set to have the desired effect?
>>>>
>>>> If so, then code would have to:
>>>>
>>>>     setReuseAddress(false);
>>>>
>>>>     if
>>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>>         this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>>
>>>>   , but at least it is explicit.
>>>>
>>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>>> they should, right? This seems to have slipped past during 6432031 [1].
>>>>
>>>> -Chris.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>
>

From chris.hegarty at oracle.com  Wed Sep 14 13:58:43 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Sep 2016 14:58:43 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
Message-ID: <b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>

One additional remark.

Was it appropriate to update the legacy MC constructors
to set the new JDK 9 SO_REUSEPORT in the first place?
This can be achievable, opt-in from new code, by creating
an unbound MS, setting the option, then binding.

-Chris.

On 14/09/16 14:47, Chris Hegarty wrote:
> Mark,
>
> On 14/09/16 14:22, Mark Sheppard wrote:
>>
>> Hi Chris,
>>      I don't fully understand your objections to the approach taken.
>> Is there a compatibility issue with the addition of the additional
>> methods to MulticastSocket?
>
> The concern is with setReuseAddress performing an operation that
> is not clear from the method specification, e.g. from setReuseAddress()
>
>      * Enable/disable the SO_REUSEADDR socket option.
>
> This is no longer accurate. The proposed changes would affect
> SO_REUSEPORT too.
>
>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
>> option, this has to be done explicitly via setOption at this level of
>> abstraction.
>
> Yes, it is a bit odd, but these are legacy classes. I am not opposed
> to adding a new method for this, or something else. I just want to
> avoid future issues and confusion when setReuseAddress is called and
> then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's
> value has changed. setReuseAddress's spec is very clear about what it
> does.
>
>> MulticastSocket is a subclass of DatagramSocket (that in itself is a
>> questionable structuring), and as such
>> has specialized behaviour, and part  of that specialization is the
>> setting of  the setting SO_REUSEADDR and SO_REUSEPORT
>> in its constructors, to enable address reuse semantics, prior to binding
>> an address.
>
> Understood. Of course, the setting of SO_REUSEPORT is new in 9,
> hence the problem.
>
>> As part of that specialization, it would seem appropriate that
>> MulticastSocket manipulate the SO_REUSEPORT
>> option in a consistent way. Adding an overridden setReuseAddress(...)
>> method provides that consistency and
>> encapsulates the specialized behaviour.
>
> I agree with the abstraction, just not that setReuseAddress should
> be used to achieve it. The name and spec of this method is so
> tied to SO_REUSEADDR.
>
>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT
>> document clearly how to handle the failing scenario, that an
>> MulticastSocket
>> requires both setReuseAddress() and a setOption call to disable
>> reuseaddress semantics on an unbound MulticastSocket ?
>
> That is one option, and the option that I was suggesting as a possible
> alternative.
>
>> This then raises the question of why have a convenience method, such as
>> setReuseAddress() in the first place, when it can be handled
>> adequately via the setOption
>
> We are moving away from these option specific getter and setter
> methods, in favor of the more general get/setOption methods, as
> the latter are more adaptable.
>
> If setReuseAddress is to operate on more than SO_REUSEADDR, then
> its spec should be very clear about this.
>
> -Chris.
>
>
>> regards
>> Mark
>>
>> On 14/09/2016 13:34, Chris Hegarty wrote:
>>> Mark,
>>>
>>> On 14/09/16 13:23, Mark Sheppard wrote:
>>>>
>>>> Hi Chris,
>>>>     so are you accepting that it is correct to add the overridden
>>>> methods in MulticastSocket and that these need
>>>> appropriate javadoc ?
>>>
>>> I think we need these, but they should just call their super
>>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
>>> exist solely as a place to locate guidance, or a note, that one
>>> will likely want to set SO_REUSEPORT too.
>>>
>>>> or are you advocating pushing the handing of the SO_REUSEPORT into the
>>>> base DatagramSocket class ?
>>>
>>> It is already there. I am not proposing to change this.
>>>
>>>> It is not clear how your code changes fit in the proposed fix i.e. the
>>>> explicit setting of the option to false?
>>>
>>> My proposal is an alternative. It is not related to the current
>>> webrev.
>>>
>>>> With the current proposed changes then I think it would be
>>>> sufficient to
>>>> invoke setReuseAddress(true) in MulticastSocket constructors
>>>> rather than
>>>>
>>>>         // Enable SO_REUSEADDR before binding
>>>>         setReuseAddress
>>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);
>>>>
>>>>
>>>>
>>>>         // Enable SO_REUSEPORT if supported before binding
>>>>         *if* (supportedOptions
>>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains
>>>>
>>>>
>>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions
>>>>
>>>>
>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>>
>>>>
>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>))
>>>>
>>>> {
>>>>             *this*.setOption
>>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions
>>>>
>>>>
>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>>
>>>>
>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,
>>>>
>>>> *true*);
>>>>         }
>>>>
>>>>
>>>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>>>
>>> Yes, this is what Vyom has proposed, in the webrev.
>>>
>>> I would like to explore an alternative, so see what it would look like.
>>>
>>> -Chris.
>>>
>>>
>>>> regards
>>>> Mark
>>>>
>>>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>>>> Vyom,
>>>>>
>>>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the below code change.
>>>>>>
>>>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>>>
>>>>>> Webrev  :
>>>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>>>>>
>>>>>> This change override the "get/setReuseAddress"  for MulticaseSocket
>>>>>> and
>>>>>> will abstract with both reuse attributes(SO_REUSEADDR &
>>>>>> SO_REUSEPORT).
>>>>>
>>>>> This issue arises since the changes for 6432031 "Add support for
>>>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>>>> the available. So setting setReuseAddress(false) alone is no longer
>>>>> sufficient to disable address/port reuse, one must also set
>>>>> SO_REUSEPORT to false.
>>>>>
>>>>> I would be really nervous about changing set/getReuseAddress, without
>>>>> at least updating the javadoc to indicate that it is now, for MS,
>>>>> operating on two socket options.  Although, I do have sympathy
>>>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>>>> dealing with multicasting.
>>>>>
>>>>> An alternative, maybe; Since the MS constructors document that
>>>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>>>> on the set/getReuseAddress methods would be sufficient, that
>>>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>>>> to be set to have the desired effect?
>>>>>
>>>>> If so, then code would have to:
>>>>>
>>>>>     setReuseAddress(false);
>>>>>
>>>>>     if
>>>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>>>         this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>>>
>>>>>   , but at least it is explicit.
>>>>>
>>>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>>>> they should, right? This seems to have slipped past during 6432031
>>>>> [1].
>>>>>
>>>>> -Chris.
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>>
>>

From mark.sheppard at oracle.com  Wed Sep 14 14:53:57 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 14 Sep 2016 15:53:57 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
Message-ID: <0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>


that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the 
same could have been argued for the original
invocation of setReuseAddress, by default , in the constructors, which 
is encapsulating, what pereceived as, common or defacto
practice wrt applying SO_REUSEADDR on mcast sockets at the system level.
As I understand it, it is generally perceived that SO_REUSEADDR and 
SO_REUSEPORT are semantically equivalent for multicast sockets.
As such, I think in the case of MulticastSocket, the fact that the 
setRuseAddress() is called in the constructor, it is appropriate
to set SO_REUSEPORT also when it exists in the OS.

I take your point on the semantics of setReuseAddress in DatagramSocket 
as per its spec. The spec does allude to MulticastSocket.
As such, the current proposal's changes just lack the appropriate 
javadoc to describe its behavior, and its additional functionality of 
setting SO_REUSEPORT.
It is not necessary that overridden method should mirror the semantics 
of the base class method.
If it is accepted that it is generally perceived that SO_REUSEADDR and 
SO_REUSEPORT are semantically equivalent for multicast sockets,
then it seems appropriate that an overriding setReuseAddress(..) method 
in MulticastSocket can reflect this.

regards
Mark



On 14/09/2016 14:58, Chris Hegarty wrote:
> One additional remark.
>
> Was it appropriate to update the legacy MC constructors
> to set the new JDK 9 SO_REUSEPORT in the first place?
> This can be achievable, opt-in from new code, by creating
> an unbound MS, setting the option, then binding.
>
> -Chris.
>
> On 14/09/16 14:47, Chris Hegarty wrote:
>> Mark,
>>
>> On 14/09/16 14:22, Mark Sheppard wrote:
>>>
>>> Hi Chris,
>>>      I don't fully understand your objections to the approach taken.
>>> Is there a compatibility issue with the addition of the additional
>>> methods to MulticastSocket?
>>
>> The concern is with setReuseAddress performing an operation that
>> is not clear from the method specification, e.g. from setReuseAddress()
>>
>>      * Enable/disable the SO_REUSEADDR socket option.
>>
>> This is no longer accurate. The proposed changes would affect
>> SO_REUSEPORT too.
>>
>>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
>>> option, this has to be done explicitly via setOption at this level of
>>> abstraction.
>>
>> Yes, it is a bit odd, but these are legacy classes. I am not opposed
>> to adding a new method for this, or something else. I just want to
>> avoid future issues and confusion when setReuseAddress is called and
>> then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's
>> value has changed. setReuseAddress's spec is very clear about what it
>> does.
>>
>>> MulticastSocket is a subclass of DatagramSocket (that in itself is a
>>> questionable structuring), and as such
>>> has specialized behaviour, and part  of that specialization is the
>>> setting of  the setting SO_REUSEADDR and SO_REUSEPORT
>>> in its constructors, to enable address reuse semantics, prior to 
>>> binding
>>> an address.
>>
>> Understood. Of course, the setting of SO_REUSEPORT is new in 9,
>> hence the problem.
>>
>>> As part of that specialization, it would seem appropriate that
>>> MulticastSocket manipulate the SO_REUSEPORT
>>> option in a consistent way. Adding an overridden setReuseAddress(...)
>>> method provides that consistency and
>>> encapsulates the specialized behaviour.
>>
>> I agree with the abstraction, just not that setReuseAddress should
>> be used to achieve it. The name and spec of this method is so
>> tied to SO_REUSEADDR.
>>
>>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT
>>> document clearly how to handle the failing scenario, that an
>>> MulticastSocket
>>> requires both setReuseAddress() and a setOption call to disable
>>> reuseaddress semantics on an unbound MulticastSocket ?
>>
>> That is one option, and the option that I was suggesting as a possible
>> alternative.
>>
>>> This then raises the question of why have a convenience method, such as
>>> setReuseAddress() in the first place, when it can be handled
>>> adequately via the setOption
>>
>> We are moving away from these option specific getter and setter
>> methods, in favor of the more general get/setOption methods, as
>> the latter are more adaptable.
>>
>> If setReuseAddress is to operate on more than SO_REUSEADDR, then
>> its spec should be very clear about this.
>>
>> -Chris.
>>
>>
>>> regards
>>> Mark
>>>
>>> On 14/09/2016 13:34, Chris Hegarty wrote:
>>>> Mark,
>>>>
>>>> On 14/09/16 13:23, Mark Sheppard wrote:
>>>>>
>>>>> Hi Chris,
>>>>>     so are you accepting that it is correct to add the overridden
>>>>> methods in MulticastSocket and that these need
>>>>> appropriate javadoc ?
>>>>
>>>> I think we need these, but they should just call their super
>>>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
>>>> exist solely as a place to locate guidance, or a note, that one
>>>> will likely want to set SO_REUSEPORT too.
>>>>
>>>>> or are you advocating pushing the handing of the SO_REUSEPORT into 
>>>>> the
>>>>> base DatagramSocket class ?
>>>>
>>>> It is already there. I am not proposing to change this.
>>>>
>>>>> It is not clear how your code changes fit in the proposed fix i.e. 
>>>>> the
>>>>> explicit setting of the option to false?
>>>>
>>>> My proposal is an alternative. It is not related to the current
>>>> webrev.
>>>>
>>>>> With the current proposed changes then I think it would be
>>>>> sufficient to
>>>>> invoke setReuseAddress(true) in MulticastSocket constructors
>>>>> rather than
>>>>>
>>>>>         // Enable SO_REUSEADDR before binding
>>>>>         setReuseAddress
>>>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*); 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         // Enable SO_REUSEPORT if supported before binding
>>>>>         *if* (supportedOptions
>>>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains 
>>>>>
>>>>>
>>>>>
>>>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions 
>>>>>
>>>>>
>>>>>
>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>>>>
>>>>>
>>>>>
>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) 
>>>>>
>>>>>
>>>>> {
>>>>>             *this*.setOption
>>>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions 
>>>>>
>>>>>
>>>>>
>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>>>>
>>>>>
>>>>>
>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>, 
>>>>>
>>>>>
>>>>> *true*);
>>>>>         }
>>>>>
>>>>>
>>>>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>>>>
>>>> Yes, this is what Vyom has proposed, in the webrev.
>>>>
>>>> I would like to explore an alternative, so see what it would look 
>>>> like.
>>>>
>>>> -Chris.
>>>>
>>>>
>>>>> regards
>>>>> Mark
>>>>>
>>>>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>>>>> Vyom,
>>>>>>
>>>>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review the below code change.
>>>>>>>
>>>>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>>>>
>>>>>>> Webrev  :
>>>>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html> 
>>>>>>>
>>>>>>>
>>>>>>> This change override the "get/setReuseAddress"  for MulticaseSocket
>>>>>>> and
>>>>>>> will abstract with both reuse attributes(SO_REUSEADDR &
>>>>>>> SO_REUSEPORT).
>>>>>>
>>>>>> This issue arises since the changes for 6432031 "Add support for
>>>>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>>>>> the available. So setting setReuseAddress(false) alone is no longer
>>>>>> sufficient to disable address/port reuse, one must also set
>>>>>> SO_REUSEPORT to false.
>>>>>>
>>>>>> I would be really nervous about changing set/getReuseAddress, 
>>>>>> without
>>>>>> at least updating the javadoc to indicate that it is now, for MS,
>>>>>> operating on two socket options.  Although, I do have sympathy
>>>>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>>>>> dealing with multicasting.
>>>>>>
>>>>>> An alternative, maybe; Since the MS constructors document that
>>>>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>>>>> on the set/getReuseAddress methods would be sufficient, that
>>>>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>>>>> to be set to have the desired effect?
>>>>>>
>>>>>> If so, then code would have to:
>>>>>>
>>>>>>     setReuseAddress(false);
>>>>>>
>>>>>>     if
>>>>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>>>> this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>>>>
>>>>>>   , but at least it is explicit.
>>>>>>
>>>>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>>>>> they should, right? This seems to have slipped past during 6432031
>>>>>> [1].
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>>>
>>>


From chris.hegarty at oracle.com  Wed Sep 14 15:17:28 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Sep 2016 16:17:28 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
Message-ID: <2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>

On 14/09/16 15:53, Mark Sheppard wrote:
>
> that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the
> same could have been argued for the original
> invocation of setReuseAddress, by default , in the constructors, which
> is encapsulating, what pereceived as, common or defacto
> practice wrt applying SO_REUSEADDR on mcast sockets at the system level.
> As I understand it, it is generally perceived that SO_REUSEADDR and
> SO_REUSEPORT are semantically equivalent for multicast sockets.
> As such, I think in the case of MulticastSocket, the fact that the
> setRuseAddress() is called in the constructor, it is appropriate
> to set SO_REUSEPORT also when it exists in the OS.
>
> I take your point on the semantics of setReuseAddress in DatagramSocket
> as per its spec. The spec does allude to MulticastSocket.
> As such, the current proposal's changes just lack the appropriate
> javadoc to describe its behavior, and its additional functionality of
> setting SO_REUSEPORT.
> It is not necessary that overridden method should mirror the semantics
> of the base class method.
> If it is accepted that it is generally perceived that SO_REUSEADDR and
> SO_REUSEPORT are semantically equivalent for multicast sockets,
> then it seems appropriate that an overriding setReuseAddress(..) method
> in MulticastSocket can reflect this.

That sounds reasonable.

-Chris.

> regards
> Mark
>
>
>
> On 14/09/2016 14:58, Chris Hegarty wrote:
>> One additional remark.
>>
>> Was it appropriate to update the legacy MC constructors
>> to set the new JDK 9 SO_REUSEPORT in the first place?
>> This can be achievable, opt-in from new code, by creating
>> an unbound MS, setting the option, then binding.
>>
>> -Chris.
>>
>> On 14/09/16 14:47, Chris Hegarty wrote:
>>> Mark,
>>>
>>> On 14/09/16 14:22, Mark Sheppard wrote:
>>>>
>>>> Hi Chris,
>>>>      I don't fully understand your objections to the approach taken.
>>>> Is there a compatibility issue with the addition of the additional
>>>> methods to MulticastSocket?
>>>
>>> The concern is with setReuseAddress performing an operation that
>>> is not clear from the method specification, e.g. from setReuseAddress()
>>>
>>>      * Enable/disable the SO_REUSEADDR socket option.
>>>
>>> This is no longer accurate. The proposed changes would affect
>>> SO_REUSEPORT too.
>>>
>>>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
>>>> option, this has to be done explicitly via setOption at this level of
>>>> abstraction.
>>>
>>> Yes, it is a bit odd, but these are legacy classes. I am not opposed
>>> to adding a new method for this, or something else. I just want to
>>> avoid future issues and confusion when setReuseAddress is called and
>>> then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's
>>> value has changed. setReuseAddress's spec is very clear about what it
>>> does.
>>>
>>>> MulticastSocket is a subclass of DatagramSocket (that in itself is a
>>>> questionable structuring), and as such
>>>> has specialized behaviour, and part  of that specialization is the
>>>> setting of  the setting SO_REUSEADDR and SO_REUSEPORT
>>>> in its constructors, to enable address reuse semantics, prior to
>>>> binding
>>>> an address.
>>>
>>> Understood. Of course, the setting of SO_REUSEPORT is new in 9,
>>> hence the problem.
>>>
>>>> As part of that specialization, it would seem appropriate that
>>>> MulticastSocket manipulate the SO_REUSEPORT
>>>> option in a consistent way. Adding an overridden setReuseAddress(...)
>>>> method provides that consistency and
>>>> encapsulates the specialized behaviour.
>>>
>>> I agree with the abstraction, just not that setReuseAddress should
>>> be used to achieve it. The name and spec of this method is so
>>> tied to SO_REUSEADDR.
>>>
>>>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT
>>>> document clearly how to handle the failing scenario, that an
>>>> MulticastSocket
>>>> requires both setReuseAddress() and a setOption call to disable
>>>> reuseaddress semantics on an unbound MulticastSocket ?
>>>
>>> That is one option, and the option that I was suggesting as a possible
>>> alternative.
>>>
>>>> This then raises the question of why have a convenience method, such as
>>>> setReuseAddress() in the first place, when it can be handled
>>>> adequately via the setOption
>>>
>>> We are moving away from these option specific getter and setter
>>> methods, in favor of the more general get/setOption methods, as
>>> the latter are more adaptable.
>>>
>>> If setReuseAddress is to operate on more than SO_REUSEADDR, then
>>> its spec should be very clear about this.
>>>
>>> -Chris.
>>>
>>>
>>>> regards
>>>> Mark
>>>>
>>>> On 14/09/2016 13:34, Chris Hegarty wrote:
>>>>> Mark,
>>>>>
>>>>> On 14/09/16 13:23, Mark Sheppard wrote:
>>>>>>
>>>>>> Hi Chris,
>>>>>>     so are you accepting that it is correct to add the overridden
>>>>>> methods in MulticastSocket and that these need
>>>>>> appropriate javadoc ?
>>>>>
>>>>> I think we need these, but they should just call their super
>>>>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
>>>>> exist solely as a place to locate guidance, or a note, that one
>>>>> will likely want to set SO_REUSEPORT too.
>>>>>
>>>>>> or are you advocating pushing the handing of the SO_REUSEPORT into
>>>>>> the
>>>>>> base DatagramSocket class ?
>>>>>
>>>>> It is already there. I am not proposing to change this.
>>>>>
>>>>>> It is not clear how your code changes fit in the proposed fix i.e.
>>>>>> the
>>>>>> explicit setting of the option to false?
>>>>>
>>>>> My proposal is an alternative. It is not related to the current
>>>>> webrev.
>>>>>
>>>>>> With the current proposed changes then I think it would be
>>>>>> sufficient to
>>>>>> invoke setReuseAddress(true) in MulticastSocket constructors
>>>>>> rather than
>>>>>>
>>>>>>         // Enable SO_REUSEADDR before binding
>>>>>>         setReuseAddress
>>>>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         // Enable SO_REUSEPORT if supported before binding
>>>>>>         *if* (supportedOptions
>>>>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>))
>>>>>>
>>>>>>
>>>>>> {
>>>>>>             *this*.setOption
>>>>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,
>>>>>>
>>>>>>
>>>>>> *true*);
>>>>>>         }
>>>>>>
>>>>>>
>>>>>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>>>>>
>>>>> Yes, this is what Vyom has proposed, in the webrev.
>>>>>
>>>>> I would like to explore an alternative, so see what it would look
>>>>> like.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>
>>>>>> regards
>>>>>> Mark
>>>>>>
>>>>>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>>>>>> Vyom,
>>>>>>>
>>>>>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review the below code change.
>>>>>>>>
>>>>>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>>>>>
>>>>>>>> Webrev  :
>>>>>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>>>>>>>
>>>>>>>>
>>>>>>>> This change override the "get/setReuseAddress"  for MulticaseSocket
>>>>>>>> and
>>>>>>>> will abstract with both reuse attributes(SO_REUSEADDR &
>>>>>>>> SO_REUSEPORT).
>>>>>>>
>>>>>>> This issue arises since the changes for 6432031 "Add support for
>>>>>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>>>>>> the available. So setting setReuseAddress(false) alone is no longer
>>>>>>> sufficient to disable address/port reuse, one must also set
>>>>>>> SO_REUSEPORT to false.
>>>>>>>
>>>>>>> I would be really nervous about changing set/getReuseAddress,
>>>>>>> without
>>>>>>> at least updating the javadoc to indicate that it is now, for MS,
>>>>>>> operating on two socket options.  Although, I do have sympathy
>>>>>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>>>>>> dealing with multicasting.
>>>>>>>
>>>>>>> An alternative, maybe; Since the MS constructors document that
>>>>>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>>>>>> on the set/getReuseAddress methods would be sufficient, that
>>>>>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>>>>>> to be set to have the desired effect?
>>>>>>>
>>>>>>> If so, then code would have to:
>>>>>>>
>>>>>>>     setReuseAddress(false);
>>>>>>>
>>>>>>>     if
>>>>>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>>>>> this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>>>>>
>>>>>>>   , but at least it is explicit.
>>>>>>>
>>>>>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>>>>>> they should, right? This seems to have slipped past during 6432031
>>>>>>> [1].
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>>>>
>>>>
>

From rob.mckenna at oracle.com  Wed Sep 14 20:37:40 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 14 Sep 2016 21:37:40 +0100
Subject: RFR - 8165988: Test JarURLConnectionUseCaches.java fails at windows:
	failed to clean up files after test
Message-ID: <20160914203740.GL5356@vimes>

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

From artem.smotrakov at oracle.com  Thu Sep 15 01:13:11 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 18:13:11 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
Message-ID: <5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>

Not urgent, but I would appreciate if someone can get a chance to look 
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
> Sending to net-dev at openjdk.java.net as well.
>
> Artem
>
>
> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>> Hello,
>>
>> Please review the following patch for 
>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>
>> The test has been observed to fail a couple of times, but it's still 
>> not clear why it failed because there is not much info in logs. The 
>> patch updates the test to enable additional debug output, so that we 
>> have more info if it fails next time.
>>
>> While looking at the test, I notices a couple of issues, but they 
>> don't seem to cause these intermittent failures:
>> - The test sets system properties for JSSE in a loop, but JSSE 
>> provider reads them only once while initialization. As a result, only 
>> values which were set in the first iteration are actually used.
>> - The test doesn't close files and sockets sometimes.
>>
>> The patch also fixed the issues above, and there are a couple 
>> cosmetic changes.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>
>> Artem
>


From xuelei.fan at oracle.com  Thu Sep 15 01:19:36 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:19:36 +0800
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
Message-ID: <20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>

As you were already there, I would suggest to consider the 
SSLSocketSample.java template as the comment in JDK-8163924 review thread.

Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
> Not urgent, but I would appreciate if someone can get a chance to look
> at this.
>
> Artem
>
>
> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>> Sending to net-dev at openjdk.java.net as well.
>>
>> Artem
>>
>>
>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> Please review the following patch for
>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>
>>> The test has been observed to fail a couple of times, but it's still
>>> not clear why it failed because there is not much info in logs. The
>>> patch updates the test to enable additional debug output, so that we
>>> have more info if it fails next time.
>>>
>>> While looking at the test, I notices a couple of issues, but they
>>> don't seem to cause these intermittent failures:
>>> - The test sets system properties for JSSE in a loop, but JSSE
>>> provider reads them only once while initialization. As a result, only
>>> values which were set in the first iteration are actually used.
>>> - The test doesn't close files and sockets sometimes.
>>>
>>> The patch also fixed the issues above, and there are a couple
>>> cosmetic changes.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>
>>> Artem
>>
>

From artem.smotrakov at oracle.com  Thu Sep 15 01:23:09 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 18:23:09 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
Message-ID: <80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>

Hi Xuelei,

For this one, I am not sure that it would help here since the test 
failed after it already had started handshaking. I would prefer to have 
it as a separate enhancement.

Artem


On 09/14/2016 06:19 PM, Xuelei Fan wrote:
> As you were already there, I would suggest to consider the 
> SSLSocketSample.java template as the comment in JDK-8163924 review 
> thread.
>
> Thanks,
> Xuelei
>
> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>> Not urgent, but I would appreciate if someone can get a chance to look
>> at this.
>>
>> Artem
>>
>>
>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>> Sending to net-dev at openjdk.java.net as well.
>>>
>>> Artem
>>>
>>>
>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>> Hello,
>>>>
>>>> Please review the following patch for
>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>
>>>> The test has been observed to fail a couple of times, but it's still
>>>> not clear why it failed because there is not much info in logs. The
>>>> patch updates the test to enable additional debug output, so that we
>>>> have more info if it fails next time.
>>>>
>>>> While looking at the test, I notices a couple of issues, but they
>>>> don't seem to cause these intermittent failures:
>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>> provider reads them only once while initialization. As a result, only
>>>> values which were set in the first iteration are actually used.
>>>> - The test doesn't close files and sockets sometimes.
>>>>
>>>> The patch also fixed the issues above, and there are a couple
>>>> cosmetic changes.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>
>>>> Artem
>>>
>>


From xuelei.fan at oracle.com  Thu Sep 15 01:39:58 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:39:58 +0800
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
Message-ID: <8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>

On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> For this one, I am not sure that it would help here since the test
> failed after it already had started handshaking.
It has the same issue as a free-port is used.  We don't actually know 
the handshake is coming from the right client.

Xuelei

> I would prefer to have it as a separate enhancement.
>
> Artem
>
>
> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>> As you were already there, I would suggest to consider the
>> SSLSocketSample.java template as the comment in JDK-8163924 review
>> thread.
>>
>> Thanks,
>> Xuelei
>>
>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>> Not urgent, but I would appreciate if someone can get a chance to look
>>> at this.
>>>
>>> Artem
>>>
>>>
>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>> Sending to net-dev at openjdk.java.net as well.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following patch for
>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>
>>>>> The test has been observed to fail a couple of times, but it's still
>>>>> not clear why it failed because there is not much info in logs. The
>>>>> patch updates the test to enable additional debug output, so that we
>>>>> have more info if it fails next time.
>>>>>
>>>>> While looking at the test, I notices a couple of issues, but they
>>>>> don't seem to cause these intermittent failures:
>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>> provider reads them only once while initialization. As a result, only
>>>>> values which were set in the first iteration are actually used.
>>>>> - The test doesn't close files and sockets sometimes.
>>>>>
>>>>> The patch also fixed the issues above, and there are a couple
>>>>> cosmetic changes.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>
>>>>> Artem
>>>>
>>>
>

From artem.smotrakov at oracle.com  Thu Sep 15 01:45:10 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 18:45:10 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
Message-ID: <4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>

Well, in this particular case it's not clear that it has the same issue 
with free port (at least to me). The exception occurred on client side, 
so it's not the case where we don't know where the handshake came from.

I can make this enhancement, but like I said I don't think it's going to 
help, so I would like to keep debug output on.

Artem


On 09/14/2016 06:39 PM, Xuelei Fan wrote:
> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>> Hi Xuelei,
>>
>> For this one, I am not sure that it would help here since the test
>> failed after it already had started handshaking.
> It has the same issue as a free-port is used.  We don't actually know 
> the handshake is coming from the right client.
>
> Xuelei
>
>> I would prefer to have it as a separate enhancement.
>>
>> Artem
>>
>>
>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>> As you were already there, I would suggest to consider the
>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>> thread.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>> at this.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following patch for
>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>
>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>> have more info if it fails next time.
>>>>>>
>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>> don't seem to cause these intermittent failures:
>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>> provider reads them only once while initialization. As a result, 
>>>>>> only
>>>>>> values which were set in the first iteration are actually used.
>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>
>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>> cosmetic changes.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>
>>>>>> Artem
>>>>>
>>>>
>>


From xuelei.fan at oracle.com  Thu Sep 15 01:55:56 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:55:56 +0800
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
Message-ID: <ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>

On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
> Well, in this particular case it's not clear that it has the same issue
> with free port (at least to me). The exception occurred on client side,
> so it's not the case where we don't know where the handshake came from.
>
;-) Yeh, you catch the point.  But there is a free-port issue although 
the exception stack in the bug description may be not that case.

Let's look at a scenarios:
1. server open a server socket and listen.
2. other test case connect to the server socket.
3. this test case try to connect to server socket.
4. this test case would fail as the server only accept one connections.

I did not check it very carefully, I think for #4, the exception stack 
can be similar to the one in the bug description.

Anyway, as a free port is used, there are free-port issues.  Please 
consider to make the enhancement in the fix.  Otherwise, you cannot 
avoid the intermittent failure for this test case in the current testing 
environment.

Xuelei

> I can make this enhancement, but like I said I don't think it's going to
> help, so I would like to keep debug output on.
>
> Artem
>
>
> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>> Hi Xuelei,
>>>
>>> For this one, I am not sure that it would help here since the test
>>> failed after it already had started handshaking.
>> It has the same issue as a free-port is used.  We don't actually know
>> the handshake is coming from the right client.
>>
>> Xuelei
>>
>>> I would prefer to have it as a separate enhancement.
>>>
>>> Artem
>>>
>>>
>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>> As you were already there, I would suggest to consider the
>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>> thread.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>>> at this.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>
>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following patch for
>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>
>>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>>> have more info if it fails next time.
>>>>>>>
>>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>>> don't seem to cause these intermittent failures:
>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>> only
>>>>>>> values which were set in the first iteration are actually used.
>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>
>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>> cosmetic changes.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>
>>>>>>> Artem
>>>>>>
>>>>>
>>>
>

From chris.hegarty at oracle.com  Thu Sep 15 07:53:17 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Sep 2016 08:53:17 +0100
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
	failed with SSLHandshakeException
In-Reply-To: <ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
Message-ID: <1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>

On 15 Sep 2016, at 02:55, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
>> Well, in this particular case it's not clear that it has the same issue
>> with free port (at least to me). The exception occurred on client side,
>> so it's not the case where we don't know where the handshake came from.
>> 
> ;-) Yeh, you catch the point.  But there is a free-port issue although the exception stack in the bug description may be not that case.
> 
> Let's look at a scenarios:
> 1. server open a server socket and listen.
> 2. other test case connect to the server socket.
> 3. this test case try to connect to server socket.
> 4. this test case would fail as the server only accept one connections.
> 
> I did not check it very carefully, I think for #4, the exception stack can be similar to the one in the bug description.
> 
> Anyway, as a free port is used, there are free-port issues.  Please consider to make the enhancement in the fix.  Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment.

+1.   Please remove any use of the free-port anti-pattern.

-Chris.

> Xuelei
> 
>> I can make this enhancement, but like I said I don't think it's going to
>> help, so I would like to keep debug output on.
>> 
>> Artem
>> 
>> 
>> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>>> Hi Xuelei,
>>>> 
>>>> For this one, I am not sure that it would help here since the test
>>>> failed after it already had started handshaking.
>>> It has the same issue as a free-port is used.  We don't actually know
>>> the handshake is coming from the right client.
>>> 
>>> Xuelei
>>> 
>>>> I would prefer to have it as a separate enhancement.
>>>> 
>>>> Artem
>>>> 
>>>> 
>>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>>> As you were already there, I would suggest to consider the
>>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>>> thread.
>>>>> 
>>>>> Thanks,
>>>>> Xuelei
>>>>> 
>>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>>>> at this.
>>>>>> 
>>>>>> Artem
>>>>>> 
>>>>>> 
>>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>> 
>>>>>>> Artem
>>>>>>> 
>>>>>>> 
>>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> Please review the following patch for
>>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>> 
>>>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>>>> have more info if it fails next time.
>>>>>>>> 
>>>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>>>> don't seem to cause these intermittent failures:
>>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>>> only
>>>>>>>> values which were set in the first iteration are actually used.
>>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>> 
>>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>>> cosmetic changes.
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>> 
>>>>>>>> Artem
>>>>>>> 
>>>>>> 
>>>> 
>> 


From daniel.fuchs at oracle.com  Thu Sep 15 09:18:46 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 15 Sep 2016 10:18:46 +0100
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
	<1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
Message-ID: <59f8ca00-cd53-3a9e-698a-401556213343@oracle.com>

On 15/09/16 08:53, Chris Hegarty wrote:
>> Anyway, as a free port is used, there are free-port issues.  Please consider to make the enhancement in the fix.  Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment.
> +1.   Please remove any use of the free-port anti-pattern.
>

Hi guys,

What is the issue of opening a server socket on port 0?
This is what the test does, I thought that was the recommended
way.

best regards,

-- daniel

> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>


From chris.hegarty at oracle.com  Thu Sep 15 12:26:59 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Sep 2016 13:26:59 +0100
Subject: RFR - 8165988: Test JarURLConnectionUseCaches.java fails at
	windows: failed to clean up files after test
In-Reply-To: <20160914203740.GL5356@vimes>
References: <20160914203740.GL5356@vimes>
Message-ID: <FC3B02CC-BA78-4ECA-B346-B0A8832FB864@oracle.com>

On 14 Sep 2016, at 21:37, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> 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/

Looks fine Rob.

-Chris.

From artem.smotrakov at oracle.com  Thu Sep 15 18:49:05 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 15 Sep 2016 11:49:05 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
	<1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
Message-ID: <6a63c9ae-0d7c-c470-2c25-2b746e1fa34b@oracle.com>

Hi Xuelei, Chris,

Thank you for looking into it. Please see inline.


On 09/15/2016 12:53 AM, Chris Hegarty wrote:
> On 15 Sep 2016, at 02:55, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
>>> Well, in this particular case it's not clear that it has the same issue
>>> with free port (at least to me). The exception occurred on client side,
>>> so it's not the case where we don't know where the handshake came from.
>>>
>> ;-) Yeh, you catch the point.  But there is a free-port issue although the exception stack in the bug description may be not that case.
>>
>> Let's look at a scenarios:
>> 1. server open a server socket and listen.
>> 2. other test case connect to the server socket.
>> 3. this test case try to connect to server socket.
>> 4. this test case would fail as the server only accept one connections.
>>
>> I did not check it very carefully, I think for #4, the exception stack can be similar to the one in the bug description.
Looks like a rare, but valid case.
>>
>> Anyway, as a free port is used, there are free-port issues.  Please consider to make the enhancement in the fix.  Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment.
> +1.   Please remove any use of the free-port anti-pattern.
Just to be clear, this is not an issue with getting a free port with 
ServerSocket.getLocalPort() and them re-using it to create a new 
ServerSocket. It's more tricky (for example, please see the scenario above).

Okay, let me update it to follow the approach which is implemented in 
SSLSocketSample.java

Artem
>
> -Chris.
>
>> Xuelei
>>
>>> I can make this enhancement, but like I said I don't think it's going to
>>> help, so I would like to keep debug output on.
>>>
>>> Artem
>>>
>>>
>>> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>>>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>>>> Hi Xuelei,
>>>>>
>>>>> For this one, I am not sure that it would help here since the test
>>>>> failed after it already had started handshaking.
>>>> It has the same issue as a free-port is used.  We don't actually know
>>>> the handshake is coming from the right client.
>>>>
>>>> Xuelei
>>>>
>>>>> I would prefer to have it as a separate enhancement.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>>>> As you were already there, I would suggest to consider the
>>>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>>>> thread.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>>>>> at this.
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>>
>>>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the following patch for
>>>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>>>
>>>>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>>>>> have more info if it fails next time.
>>>>>>>>>
>>>>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>>>>> don't seem to cause these intermittent failures:
>>>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>>>> only
>>>>>>>>> values which were set in the first iteration are actually used.
>>>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>>>
>>>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>>>> cosmetic changes.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>>>
>>>>>>>>> Artem


From sergei.kovalev at oracle.com  Mon Sep 19 14:33:53 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Mon, 19 Sep 2016 17:33:53 +0300
Subject: RFR(s): 8166285: Missing dependencies java.httpclient for tests from
	java/net pachage
Message-ID: <344b5ddd-0848-b5d6-8d76-fa4679cf6bcb@oracle.com>

Hello team,

Could you please review below fix for:

BugID: https://bugs.openjdk.java.net/browse/JDK-8166285
Webrev: http://cr.openjdk.java.net/~skovalev/8166285/webrev.00/

Issue: Several regression tests from java/net package failing on 
execution in case an option "--limi-modules java/base" provided.
Solution: add missed modules declaration in appropriate test header.
More details see in CR.

-- 
With best regards,
Sergei


From chris.hegarty at oracle.com  Tue Sep 20 07:53:58 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 20 Sep 2016 08:53:58 +0100
Subject: RFR(s): 8166285: Missing dependencies java.httpclient for tests
	from java/net pachage
In-Reply-To: <344b5ddd-0848-b5d6-8d76-fa4679cf6bcb@oracle.com>
References: <344b5ddd-0848-b5d6-8d76-fa4679cf6bcb@oracle.com>
Message-ID: <14FBA314-6D1D-43EB-8422-8290FE138499@oracle.com>


> On 19 Sep 2016, at 15:33, Sergei Kovalev <sergei.kovalev at oracle.com> wrote:
> 
> Hello team,
> 
> Could you please review below fix for:
> 
> BugID: https://bugs.openjdk.java.net/browse/JDK-8166285
> Webrev: http://cr.openjdk.java.net/~skovalev/8166285/webrev.00/

Reviewed. Thanks Sergei.

-Chris.

> Issue: Several regression tests from java/net package failing on execution in case an option "--limi-modules java/base" provided.
> Solution: add missed modules declaration in appropriate test header.
> More details see in CR.
> 
> -- 
> With best regards,
> Sergei
> 


From felix.yang at oracle.com  Tue Sep 20 12:57:28 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 20 Sep 2016 20:57:28 +0800
Subject: RFR 8166359/9,
	java/net/URLPermission/nstest/lookup.sh fails if proxy is set,
	since fix for JDK-8161016
Message-ID: <1437A7E2-7776-4301-9972-BAE9689843DE@oracle.com>

Hi all,
    please review the following test fix. It explicitly disables proxy to make sure the test not affected by different environment configuration.

Bug:
    https://bugs.openjdk.java.net/browse/JDK-8166359

Webrev: 
     http://cr.openjdk.java.net/~xiaofeya/8166359/webrev.00/ <http://cr.openjdk.java.net/~xiaofeya/8166359/webrev.00/>

Thanks,
Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160920/199460b8/attachment.html>

From chris.hegarty at oracle.com  Tue Sep 20 15:22:41 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 20 Sep 2016 16:22:41 +0100
Subject: RFR 8166359/9,
	java/net/URLPermission/nstest/lookup.sh fails if proxy is set,
	since fix for JDK-8161016
In-Reply-To: <1437A7E2-7776-4301-9972-BAE9689843DE@oracle.com>
References: <1437A7E2-7776-4301-9972-BAE9689843DE@oracle.com>
Message-ID: <D1CAECEC-099E-4891-BB37-636D8040DD6A@oracle.com>

Felix,

> On 20 Sep 2016, at 13:57, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Hi all,
>     please review the following test fix. It explicitly disables proxy to make sure the test not affected by different environment configuration.
> 
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8166359
> 
> Webrev: 
>      http://cr.openjdk.java.net/~xiaofeya/8166359/webrev.00/

Since the test is setting a system-wide proxy selector, should it run in
othervm mode ?

Also, it is not clear to me why the change from ?test.src? to ?user.dir?,
since the file being access is actual in the test source root, right?

-Chris.


From artem.smotrakov at oracle.com  Tue Sep 20 21:50:05 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 20 Sep 2016 14:50:05 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <6a63c9ae-0d7c-c470-2c25-2b746e1fa34b@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
	<1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
	<6a63c9ae-0d7c-c470-2c25-2b746e1fa34b@oracle.com>
Message-ID: <41b8c228-1652-7b5a-ecf9-765e2e95afb8@oracle.com>

Hello,

If you don't mind, I moved some common code from SSLSocketTemplate.java 
to SSLTest.java, so that it can be re-used by other tests. It may help 
to avoid duplicate code.

http://cr.openjdk.java.net/~asmotrak/8164591/webrev.01/

Please take a look.

Artem


On 09/15/2016 11:49 AM, Artem Smotrakov wrote:
> Hi Xuelei, Chris,
>
> Thank you for looking into it. Please see inline.
>
>
> On 09/15/2016 12:53 AM, Chris Hegarty wrote:
>> On 15 Sep 2016, at 02:55, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
>>>> Well, in this particular case it's not clear that it has the same 
>>>> issue
>>>> with free port (at least to me). The exception occurred on client 
>>>> side,
>>>> so it's not the case where we don't know where the handshake came 
>>>> from.
>>>>
>>> ;-) Yeh, you catch the point.  But there is a free-port issue 
>>> although the exception stack in the bug description may be not that 
>>> case.
>>>
>>> Let's look at a scenarios:
>>> 1. server open a server socket and listen.
>>> 2. other test case connect to the server socket.
>>> 3. this test case try to connect to server socket.
>>> 4. this test case would fail as the server only accept one connections.
>>>
>>> I did not check it very carefully, I think for #4, the exception 
>>> stack can be similar to the one in the bug description.
> Looks like a rare, but valid case.
>>>
>>> Anyway, as a free port is used, there are free-port issues. Please 
>>> consider to make the enhancement in the fix. Otherwise, you cannot 
>>> avoid the intermittent failure for this test case in the current 
>>> testing environment.
>> +1.   Please remove any use of the free-port anti-pattern.
> Just to be clear, this is not an issue with getting a free port with 
> ServerSocket.getLocalPort() and them re-using it to create a new 
> ServerSocket. It's more tricky (for example, please see the scenario 
> above).
>
> Okay, let me update it to follow the approach which is implemented in 
> SSLSocketSample.java
>
> Artem
>>
>> -Chris.
>>
>>> Xuelei
>>>
>>>> I can make this enhancement, but like I said I don't think it's 
>>>> going to
>>>> help, so I would like to keep debug output on.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>>>>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>>>>> Hi Xuelei,
>>>>>>
>>>>>> For this one, I am not sure that it would help here since the test
>>>>>> failed after it already had started handshaking.
>>>>> It has the same issue as a free-port is used.  We don't actually know
>>>>> the handshake is coming from the right client.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>> I would prefer to have it as a separate enhancement.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>
>>>>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>>>>> As you were already there, I would suggest to consider the
>>>>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>>>>> thread.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>>>>> Not urgent, but I would appreciate if someone can get a chance 
>>>>>>>> to look
>>>>>>>> at this.
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the following patch for
>>>>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>>>>
>>>>>>>>>> The test has been observed to fail a couple of times, but 
>>>>>>>>>> it's still
>>>>>>>>>> not clear why it failed because there is not much info in 
>>>>>>>>>> logs. The
>>>>>>>>>> patch updates the test to enable additional debug output, so 
>>>>>>>>>> that we
>>>>>>>>>> have more info if it fails next time.
>>>>>>>>>>
>>>>>>>>>> While looking at the test, I notices a couple of issues, but 
>>>>>>>>>> they
>>>>>>>>>> don't seem to cause these intermittent failures:
>>>>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>>>>> only
>>>>>>>>>> values which were set in the first iteration are actually used.
>>>>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>>>>
>>>>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>>>>> cosmetic changes.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Artem
>


From felix.yang at oracle.com  Wed Sep 21 02:31:38 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Wed, 21 Sep 2016 10:31:38 +0800
Subject: RFR 8166359/9, java/net/URLPermission/nstest/lookup.sh fails if
	proxy is set, since fix for JDK-8161016
In-Reply-To: <D1CAECEC-099E-4891-BB37-636D8040DD6A@oracle.com>
References: <1437A7E2-7776-4301-9972-BAE9689843DE@oracle.com>
	<D1CAECEC-099E-4891-BB37-636D8040DD6A@oracle.com>
Message-ID: <fad96368-4542-c4db-5170-c26f111eb459@oracle.com>

Hi Chris,


On 2016/9/20 23:22, Chris Hegarty wrote:
> Felix,
>
>> On 20 Sep 2016, at 13:57, Felix Yang <felix.yang at oracle.com> wrote:
>>
>> Hi all,
>>      please review the following test fix. It explicitly disables proxy to make sure the test not affected by different environment configuration.
>>
>> Bug:
>>      https://bugs.openjdk.java.net/browse/JDK-8166359
>>
>> Webrev:
>>       http://cr.openjdk.java.net/~xiaofeya/8166359/webrev.00/
> Since the test is setting a system-wide proxy selector, should it run in
> othervm mode ?
This test is shell test. I guess it is 'othervm' in nature, right?

-Felix
>
> Also, it is not clear to me why the change from ?test.src? to ?user.dir?,
> since the file being access is actual in the test source root, right?
Two things here:
1. Not sure the test history, since no bug it associated. It looks that 
file is even not necessary.
     Could you suggest if it can be removed directly.
2. I remember modifying files under "test.src" is not suggested approach.

-Felix
>
> -Chris.
>


From chris.hegarty at oracle.com  Wed Sep 21 09:04:10 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 21 Sep 2016 10:04:10 +0100
Subject: RFR 8166359/9, java/net/URLPermission/nstest/lookup.sh fails if
	proxy is set, since fix for JDK-8161016
In-Reply-To: <fad96368-4542-c4db-5170-c26f111eb459@oracle.com>
References: <1437A7E2-7776-4301-9972-BAE9689843DE@oracle.com>
	<D1CAECEC-099E-4891-BB37-636D8040DD6A@oracle.com>
	<fad96368-4542-c4db-5170-c26f111eb459@oracle.com>
Message-ID: <f9316788-9114-2dab-c692-7e85a3524ce0@oracle.com>

Felix,

On 21/09/16 03:31, Felix Yang wrote:
> Hi Chris,
>
>
> On 2016/9/20 23:22, Chris Hegarty wrote:
>> Felix,
>>
>>> On 20 Sep 2016, at 13:57, Felix Yang <felix.yang at oracle.com> wrote:
>>>
>>> Hi all,
>>>      please review the following test fix. It explicitly disables
>>> proxy to make sure the test not affected by different environment
>>> configuration.
>>>
>>> Bug:
>>>      https://bugs.openjdk.java.net/browse/JDK-8166359
>>>
>>> Webrev:
>>>       http://cr.openjdk.java.net/~xiaofeya/8166359/webrev.00/
>> Since the test is setting a system-wide proxy selector, should it run in
>> othervm mode ?
> This test is shell test. I guess it is 'othervm' in nature, right?

D'oh, yes of course.

> -Felix
>>
>> Also, it is not clear to me why the change from ?test.src? to ?user.dir?,
>> since the file being access is actual in the test source root, right?
> Two things here:
> 1. Not sure the test history, since no bug it associated. It looks that
> file is even not necessary.
>     Could you suggest if it can be removed directly.

Looking at the code more closely, I now see that this file is indeed
not needed. Please keep your change ( to use user.dir ), and remove
the LookupTestHosts file ( as it is effectively generated by the test ).

> 2. I remember modifying files under "test.src" is not suggested approach.

Right. If the test has a read-only file that provides some configuration
then test.src is fine. If the test is generating something, or just
writing to a file, then the current working directory ( jtreg scratch )
is best.

-Chris.


> -Felix
>>
>> -Chris.
>>
>

From rob.mckenna at oracle.com  Wed Sep 21 15:16:46 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 21 Sep 2016 16:16:46 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non existing
	IP addresses
Message-ID: <20160921151646.GD5168@vimes>

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 number of common failure causes into account before deciding to throw an exception.

http://cr.openjdk.java.net/~robm/8159410/webrev.01/

	-Rob

From christoph.langer at sap.com  Wed Sep 21 15:28:08 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 21 Sep 2016 15:28:08 +0000
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing	IP addresses
In-Reply-To: <20160921151646.GD5168@vimes>
References: <20160921151646.GD5168@vimes>
Message-ID: <612ec124ee01468a8bd3cc546a38b90e@DEWDFE13DE11.global.corp.sap>

Hi Rob,

this looks like a nice fix and I can't see anything besides the copyright year which you will for sure update when submitting. :)

Unfortunately I'm not a reviewer so you'll have to get another real review.

Best regards
Christoph

> -----Original Message-----
> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Rob
> McKenna
> Sent: Mittwoch, 21. September 2016 17:17
> To: net-dev at openjdk.java.net
> Subject: RFR - 8159410: InetAddress.isReachable returns true for non existing IP
> addresses
> 
> 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 number of common failure causes
> into account before deciding to throw an exception.
> 
> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> 
> 	-Rob

From vyom.tewari at oracle.com  Wed Sep 21 16:18:54 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 21 Sep 2016 21:48:54 +0530
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <20160921151646.GD5168@vimes>
References: <20160921151646.GD5168@vimes>
Message-ID: <0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>

Hi Rob,

Do you really think this extra check is required ?

if (pEchoReply->Status == IP_SUCCESS
+ && (int)pEchoReply->RoundTripTime <= timeout) I did not found any 
doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>
> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>
> 	-Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160921/0a2fc141/attachment.html>

From mark.sheppard at oracle.com  Wed Sep 21 16:35:17 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 21 Sep 2016 17:35:17 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <20160921151646.GD5168@vimes>
References: <20160921151646.GD5168@vimes>
Message-ID: <7b007776-6a2b-4b3c-c100-5c898665d68d@oracle.com>

Hi Rob,
      this looks good ...

do you think there is any need to replicate these changes in 
Inet6AddressImpl.c ?     (or leave it alone and don't trouble trouble 
until trouble troubles you :-)

regards
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 call itself failed or succeeded. This change checks that both the call and the ping were successful. In addition to that it takes a number of common failure causes into account before deciding to throw an exception.
>
> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>
> 	-Rob


From mark.sheppard at oracle.com  Wed Sep 21 16:42:37 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 21 Sep 2016 17:42:37 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
Message-ID: <5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>


the IcmpSendEcho series of calls come with some idiosyncrasies in that 
there is a minimum timeout that they can handle
think it is about 1000msecs. isReachable can specify a finer grained 
timeout hence the need for timeout check

regards
Mark

On 21/09/2016 17:18, Vyom Tewari wrote:
>
> Hi Rob,
>
> Do you really think this extra check is required ?
>
> if (pEchoReply->Status == IP_SUCCESS
> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any 
> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>>
>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>>
>> 	-Rob
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160921/4d129e2b/attachment.html>

From rob.mckenna at oracle.com  Wed Sep 21 17:08:40 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 21 Sep 2016 18:08:40 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <7b007776-6a2b-4b3c-c100-5c898665d68d@oracle.com>
References: <20160921151646.GD5168@vimes>
	<7b007776-6a2b-4b3c-c100-5c898665d68d@oracle.com>
Message-ID: <20160921170840.GF5168@vimes>

It's absolutely worth looking into and I'll get going on that, but I'd rather deal with it separately to the ipv4 stuff. IcmpSendEcho already appears to behave somewhat strangely, so I wouldn't necessarily assume that the ipv4 and ipv6 code will end up being identical.

	-Rob

On 21/09/16 05:35, Mark Sheppard wrote:
> Hi Rob,
>      this looks good ...
> 
> do you think there is any need to replicate these changes in
> Inet6AddressImpl.c ?     (or leave it alone and don't trouble trouble until
> trouble troubles you :-)
> 
> regards
> 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 call itself failed or succeeded. This change checks that both the call and the ping were successful. In addition to that it takes a number of common failure causes into account before deciding to throw an exception.
> >
> >http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> >
> >	-Rob
> 

From rob.mckenna at oracle.com  Wed Sep 21 17:09:33 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 21 Sep 2016 18:09:33 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
Message-ID: <20160921170933.GG5168@vimes>

Unfortunately the behaviour described is undocumented and was found the hard way. This part of the code is a necessity though.

	-Rob

On 21/09/16 09:48, Vyom Tewari wrote:
> Hi Rob,
> 
> Do you really think this extra check is required ?
> 
> if (pEchoReply->Status == IP_SUCCESS
> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
> >
> >http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> >
> >	-Rob
> 

From sean.coffey at oracle.com  Wed Sep 21 17:32:04 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 21 Sep 2016 18:32:04 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
Message-ID: <57E2C414.3030207@oracle.com>

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 timeout that they can handle
> think it is about 1000msecs. isReachable can specify a finer grained 
> timeout hence the need for timeout check
>
> regards
> Mark
>
> On 21/09/2016 17:18, Vyom Tewari wrote:
>>
>> Hi Rob,
>>
>> Do you really think this extra check is required ?
>>
>> if (pEchoReply->Status == IP_SUCCESS
>> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any 
>> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>>>
>>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>>>
>>> 	-Rob
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160921/2581a301/attachment.html>

From vyom.tewari at oracle.com  Wed Sep 21 17:37:33 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 21 Sep 2016 23:07:33 +0530
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <20160921170933.GG5168@vimes>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<20160921170933.GG5168@vimes>
Message-ID: <538d0d8a-a2c8-d2b7-61af-5412cd686be6@oracle.com>

So InetAddress.isReachable() will return false 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. This part of the code is a necessity though.
>
> 	-Rob
>
> On 21/09/16 09:48, Vyom Tewari wrote:
>> Hi Rob,
>>
>> Do you really think this extra check is required ?
>>
>> if (pEchoReply->Status == IP_SUCCESS
>> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
>> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>>>
>>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>>>
>>> 	-Rob


From rob.mckenna at oracle.com  Wed Sep 21 18:07:00 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 21 Sep 2016 19:07:00 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <538d0d8a-a2c8-d2b7-61af-5412cd686be6@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<20160921170933.GG5168@vimes>
	<538d0d8a-a2c8-d2b7-61af-5412cd686be6@oracle.com>
Message-ID: <20160921180700.GH5168@vimes>

Yup. To elabourate:

If we set a small timeout for a faraway host with a high ping, IcmpSendEcho can report success even if the rtt exceeded the timeout, hence the need for this explicit check.

	-Rob

On 21/09/16 11:07, Vyom Tewari wrote:
> So InetAddress.isReachable() will return false 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. This part of the code is a necessity though.
> >
> >	-Rob
> >
> >On 21/09/16 09:48, Vyom Tewari wrote:
> >>Hi Rob,
> >>
> >>Do you really think this extra check is required ?
> >>
> >>if (pEchoReply->Status == IP_SUCCESS
> >>+ && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
> >>doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
> >>>
> >>>http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> >>>
> >>>	-Rob
> 

From rob.mckenna at oracle.com  Wed Sep 21 18:44:49 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 21 Sep 2016 19:44:49 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <57E2C414.3030207@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
	<57E2C414.3030207@oracle.com>
Message-ID: <20160921184449.GI5168@vimes>

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 tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:

https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx

	-Rob

On 21/09/16 06:32, Se?n Coffey wrote:
> 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 timeout that they can handle
> >think it is about 1000msecs. isReachable can specify a finer grained
> >timeout hence the need for timeout check
> >
> >regards
> >Mark
> >
> >On 21/09/2016 17:18, Vyom Tewari wrote:
> >>
> >>Hi Rob,
> >>
> >>Do you really think this extra check is required ?
> >>
> >>if (pEchoReply->Status == IP_SUCCESS
> >>+ && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
> >>doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
> >>>
> >>>http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> >>>
> >>>	-Rob
> >>
> >
> 

From rob.mckenna at oracle.com  Wed Sep 21 18:45:54 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 21 Sep 2016 19:45:54 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <20160921184449.GI5168@vimes>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
	<57E2C414.3030207@oracle.com> <20160921184449.GI5168@vimes>
Message-ID: <20160921184554.GJ5168@vimes>

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 tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:
> 
> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx
> 
> 	-Rob
> 
> On 21/09/16 06:32, Se?n Coffey wrote:
> > 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 timeout that they can handle
> > >think it is about 1000msecs. isReachable can specify a finer grained
> > >timeout hence the need for timeout check
> > >
> > >regards
> > >Mark
> > >
> > >On 21/09/2016 17:18, Vyom Tewari wrote:
> > >>
> > >>Hi Rob,
> > >>
> > >>Do you really think this extra check is required ?
> > >>
> > >>if (pEchoReply->Status == IP_SUCCESS
> > >>+ && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
> > >>doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
> > >>>
> > >>>http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> > >>>
> > >>>	-Rob
> > >>
> > >
> > 

From martinrb at google.com  Wed Sep 21 21:14:14 2016
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 21 Sep 2016 14:14:14 -0700
Subject: HTTP client API
In-Reply-To: <57D04B47.1030805@oracle.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<57D04B47.1030805@oracle.com>
Message-ID: <CA+kOe09N5AQfwWfo6o0h7NqKNsBd1ewvDbrOORRBDPrDV=7B8Q@mail.gmail.com>

On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon <
michael.x.mcmahon at oracle.com> wrote:

>
> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>
> [2] http://cr.openjdk.java.net/~michaelm/httpclient/
> specdiffout.1/package-summary.html
>

Could we have actual source code for experimentation by interested parties?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160921/eb537da3/attachment-0001.html>

From michael.x.mcmahon at oracle.com  Wed Sep 21 23:14:31 2016
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 21 Sep 2016 16:14:31 -0700
Subject: HTTP client API
In-Reply-To: <CA+kOe09N5AQfwWfo6o0h7NqKNsBd1ewvDbrOORRBDPrDV=7B8Q@mail.gmail.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<57D04B47.1030805@oracle.com>
	<CA+kOe09N5AQfwWfo6o0h7NqKNsBd1ewvDbrOORRBDPrDV=7B8Q@mail.gmail.com>
Message-ID: <57E31457.3010801@oracle.com>

Martin

The source is available in the JDK 9 sandbox (http-client-branch) at
http://hg.openjdk.java.net/jdk9/sandbox/

I think it has been updated to reflect the API as described below.

Michael.

On 21/09/2016, 14:14, Martin Buchholz wrote:
>
>
> On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon 
> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at oracle.com>> 
> wrote:
>
>
>     [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/api.1/>
>
>     [2]
>     http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html
>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/specdiffout.1/package-summary.html>
>
>
> Could we have actual source code for experimentation by interested 
> parties?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160921/6ca90242/attachment.html>

From chris.hegarty at oracle.com  Thu Sep 22 07:54:12 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 22 Sep 2016 08:54:12 +0100
Subject: HTTP client API
In-Reply-To: <57E31457.3010801@oracle.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<57D04B47.1030805@oracle.com>
	<CA+kOe09N5AQfwWfo6o0h7NqKNsBd1ewvDbrOORRBDPrDV=7B8Q@mail.gmail.com>
	<57E31457.3010801@oracle.com>
Message-ID: <17F9D73F-196D-44CC-BAFF-CD7648786BF7@oracle.com>

On 22 Sep 2016, at 00:14, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> Martin
> 
> The source is available in the JDK 9 sandbox (http-client-branch) at
> http://hg.openjdk.java.net/jdk9/sandbox/
> 
> I think it has been updated to reflect the API as described below.

Apologies, it has not been update yet. I will do it over the next day, or so, and
post a note when it is done.

-Chris.

> Michael.
> 
> On 21/09/2016, 14:14, Martin Buchholz wrote:
>> 
>> 
>> On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>> 
>> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>> 
>> [2] http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html
>> 
>> Could we have actual source code for experimentation by interested parties?


From mark.sheppard at oracle.com  Thu Sep 22 17:04:52 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Thu, 22 Sep 2016 18:04:52 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <20160921184554.GJ5168@vimes>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
	<57E2C414.3030207@oracle.com> <20160921184449.GI5168@vimes>
	<20160921184554.GJ5168@vimes>
Message-ID: <371439af-bed8-b8e3-a434-22e400189722@oracle.com>


it is good that you added  the additional error code, "cover all bases", 
as they say.
In any case your exception handling will inform if  something has been 
missed, should it occur.
So at the risk of triggering another MS curiosity, the changes look fine

regards
Mark

On 21/09/2016 19:45, Rob McKenna wrote:
> 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 tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:
>>
>> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx
>>
>> 	-Rob
>>
>> On 21/09/16 06:32, Se?n Coffey wrote:
>>> 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 timeout that they can handle
>>>> think it is about 1000msecs. isReachable can specify a finer grained
>>>> timeout hence the need for timeout check
>>>>
>>>> regards
>>>> Mark
>>>>
>>>> On 21/09/2016 17:18, Vyom Tewari wrote:
>>>>> Hi Rob,
>>>>>
>>>>> Do you really think this extra check is required ?
>>>>>
>>>>> if (pEchoReply->Status == IP_SUCCESS
>>>>> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
>>>>> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>>>>>>
>>>>>> 	-Rob


From chris.hegarty at oracle.com  Thu Sep 22 17:12:55 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 22 Sep 2016 18:12:55 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <371439af-bed8-b8e3-a434-22e400189722@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
	<57E2C414.3030207@oracle.com> <20160921184449.GI5168@vimes>
	<20160921184554.GJ5168@vimes>
	<371439af-bed8-b8e3-a434-22e400189722@oracle.com>
Message-ID: <36AE3D6E-611D-4277-BE21-A2D2432199ED@oracle.com>


> On 22 Sep 2016, at 18:04, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> 
> it is good that you added  the additional error code, "cover all bases", as they say.
> In any case your exception 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:
>> 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 tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:
>>> 
>>> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx
>>> 
>>> 	-Rob
>>> 
>>> On 21/09/16 06:32, Se?n Coffey wrote:
>>>> 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 timeout that they can handle
>>>>> think it is about 1000msecs. isReachable can specify a finer grained
>>>>> timeout hence the need for timeout check
>>>>> 
>>>>> regards
>>>>> Mark
>>>>> 
>>>>> On 21/09/2016 17:18, Vyom Tewari wrote:
>>>>>> Hi Rob,
>>>>>> 
>>>>>> Do you really think this extra check is required ?
>>>>>> 
>>>>>> if (pEchoReply->Status == IP_SUCCESS
>>>>>> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
>>>>>> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>>>>>>> 
>>>>>>> 	-Rob
> 


From rob.mckenna at oracle.com  Thu Sep 22 18:22:23 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 22 Sep 2016 19:22:23 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <36AE3D6E-611D-4277-BE21-A2D2432199ED@oracle.com>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
	<57E2C414.3030207@oracle.com> <20160921184449.GI5168@vimes>
	<20160921184554.GJ5168@vimes>
	<371439af-bed8-b8e3-a434-22e400189722@oracle.com>
	<36AE3D6E-611D-4277-BE21-A2D2432199ED@oracle.com>
Message-ID: <20160922182223.GF5040@vimes>

Thanks folks,

I've been running some testing here and noticed that IP_REQ_TIMED_OUT can also be returned from IcmpSendEcho (as opposed to only being an error code in an ICMP_ECHO_REPLY)

Updated webrev here:

http://cr.openjdk.java.net/~robm/8159410/webrev.03/

	-Rob

On 22/09/16 06:12, Chris Hegarty wrote:
> 
> > On 22 Sep 2016, at 18:04, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> > 
> > 
> > it is good that you added  the additional error code, "cover all bases", as they say.
> > In any case your exception 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:
> >> 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 tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:
> >>> 
> >>> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx
> >>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx
> >>> 
> >>> 	-Rob
> >>> 
> >>> On 21/09/16 06:32, Se?n Coffey wrote:
> >>>> 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 timeout that they can handle
> >>>>> think it is about 1000msecs. isReachable can specify a finer grained
> >>>>> timeout hence the need for timeout check
> >>>>> 
> >>>>> regards
> >>>>> Mark
> >>>>> 
> >>>>> On 21/09/2016 17:18, Vyom Tewari wrote:
> >>>>>> Hi Rob,
> >>>>>> 
> >>>>>> Do you really think this extra check is required ?
> >>>>>> 
> >>>>>> if (pEchoReply->Status == IP_SUCCESS
> >>>>>> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
> >>>>>> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
> >>>>>>> 
> >>>>>>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
> >>>>>>> 
> >>>>>>> 	-Rob
> > 
> 

From christoph.langer at sap.com  Thu Sep 22 20:59:29 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 22 Sep 2016 20:59:29 +0000
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
Message-ID: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>

Hi,

while looking at utility functions for creating exceptions in libjava/libnet I found a small spot that should be consolidated right away.

The function NET_ThrowSocketException does only exist in the windows native implementation and is only used in 3 places in SocketInputStream.c. I removed this in favor of directly calling JNU_ThrowByName as the Unix variant of that code already does.

In that function Java_java_net_SocketInputStream_socketRead0 I also replaced throwing a SocketException with throwing an NPE in the rare case that a the JNI input for the file descriptor is null. That's probably more natural and should virtually never occur anyways.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/

Thanks in advance for reviewing :)

Best regards
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160922/f8d1536e/attachment-0001.html>

From felix.yang at oracle.com  Fri Sep 23 09:21:14 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 23 Sep 2016 17:21:14 +0800
Subject: RFR 8085049/9, java/net/MulticastSocket/TimeToLive.java fails
	intermittently with "Address already in use"
Message-ID: <ecf67958-82f8-788c-3abc-b69437a13737@oracle.com>

Hi there,

     please review a minor test fix to avoid hard-coded port usage, 
which leads to "Address already in use" issue intermittently.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8085049

Since it is just a 1 line change, just print the patch here:

diff -r 83030d149c5c test/java/net/MulticastSocket/TimeToLive.java
--- a/test/java/net/MulticastSocket/TimeToLive.java     Fri Sep 23 
01:08:24 2016 +0000
+++ b/test/java/net/MulticastSocket/TimeToLive.java     Fri Sep 23 
01:39:24 2016 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -37,7 +37,7 @@
      static int[] bad_ttls = { -1, 256 };

      public static void main(String[] args) throws Exception {
-        MulticastSocket socket = new MulticastSocket(6789);
+        MulticastSocket socket = new MulticastSocket();
          int ttl = socket.getTimeToLive();
          System.out.println("default ttl: " + ttl);
          for (int i = 0; i < new_ttls.length; i++) {


Thanks,

Felix


From chris.hegarty at oracle.com  Fri Sep 23 09:40:06 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 23 Sep 2016 10:40:06 +0100
Subject: RFR 8085049/9, java/net/MulticastSocket/TimeToLive.java fails
	intermittently with "Address already in use"
In-Reply-To: <ecf67958-82f8-788c-3abc-b69437a13737@oracle.com>
References: <ecf67958-82f8-788c-3abc-b69437a13737@oracle.com>
Message-ID: <3141af44-2499-21b7-b0ef-3582d9bb23c0@oracle.com>

Looks good. Thanks Felix.

-Chris.

On 23/09/16 10:21, Felix Yang wrote:
> Hi there,
>
>     please review a minor test fix to avoid hard-coded port usage, which
> leads to "Address already in use" issue intermittently.
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8085049
>
> Since it is just a 1 line change, just print the patch here:
>
> diff -r 83030d149c5c test/java/net/MulticastSocket/TimeToLive.java
> --- a/test/java/net/MulticastSocket/TimeToLive.java     Fri Sep 23
> 01:08:24 2016 +0000
> +++ b/test/java/net/MulticastSocket/TimeToLive.java     Fri Sep 23
> 01:39:24 2016 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -37,7 +37,7 @@
>      static int[] bad_ttls = { -1, 256 };
>
>      public static void main(String[] args) throws Exception {
> -        MulticastSocket socket = new MulticastSocket(6789);
> +        MulticastSocket socket = new MulticastSocket();
>          int ttl = socket.getTimeToLive();
>          System.out.println("default ttl: " + ttl);
>          for (int i = 0; i < new_ttls.length; i++) {
>
>
> Thanks,
>
> Felix
>

From chris.hegarty at oracle.com  Fri Sep 23 09:58:49 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 23 Sep 2016 10:58:49 +0100
Subject: RFR - 8159410: InetAddress.isReachable returns true for non
	existing IP addresses
In-Reply-To: <20160922182223.GF5040@vimes>
References: <20160921151646.GD5168@vimes>
	<0a27f57b-1dfe-2e81-dd1f-0e34692397cc@oracle.com>
	<5d75efeb-3c4a-5674-1c76-d71607e759e4@oracle.com>
	<57E2C414.3030207@oracle.com> <20160921184449.GI5168@vimes>
	<20160921184554.GJ5168@vimes>
	<371439af-bed8-b8e3-a434-22e400189722@oracle.com>
	<36AE3D6E-611D-4277-BE21-A2D2432199ED@oracle.com>
	<20160922182223.GF5040@vimes>
Message-ID: <729f417c-33d2-4e62-9184-390a1a84839a@oracle.com>

On 22/09/16 19:22, Rob McKenna wrote:
> Thanks folks,
>
> I've been running some testing here and noticed that IP_REQ_TIMED_OUT can also be returned from IcmpSendEcho (as opposed to only being an error code in an ICMP_ECHO_REPLY)
>
> Updated webrev here:
>
> http://cr.openjdk.java.net/~robm/8159410/webrev.03/

Thanks Rob. This latest version looks good to me.

-Chris.

> 	-Rob
>
> On 22/09/16 06:12, Chris Hegarty wrote:
>>
>>> On 22 Sep 2016, at 18:04, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>>
>>>
>>> it is good that you added  the additional error code, "cover all bases", as they say.
>>> In any case your exception 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:
>>>> 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 tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:
>>>>>
>>>>> https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx
>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx
>>>>>
>>>>> 	-Rob
>>>>>
>>>>> On 21/09/16 06:32, Se?n Coffey wrote:
>>>>>> 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 timeout that they can handle
>>>>>>> think it is about 1000msecs. isReachable can specify a finer grained
>>>>>>> timeout hence the need for timeout check
>>>>>>>
>>>>>>> regards
>>>>>>> Mark
>>>>>>>
>>>>>>> On 21/09/2016 17:18, Vyom Tewari wrote:
>>>>>>>> Hi Rob,
>>>>>>>>
>>>>>>>> Do you really think this extra check is required ?
>>>>>>>>
>>>>>>>> if (pEchoReply->Status == IP_SUCCESS
>>>>>>>> + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
>>>>>>>> doc(MSDN) which explains 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 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 number of common failure causes into account before deciding to throw an exception.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~robm/8159410/webrev.01/
>>>>>>>>>
>>>>>>>>> 	-Rob
>>>
>>

From chris.hegarty at oracle.com  Fri Sep 23 14:24:53 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 23 Sep 2016 15:24:53 +0100
Subject: HTTP client API
In-Reply-To: <17F9D73F-196D-44CC-BAFF-CD7648786BF7@oracle.com>
References: <57BAB039.9030700@oracle.com>
	<CAD3-0rMm9yNVt0r+jYmOpM8e_oy-_m+jCd6OqxHJJ22TOgf1UQ@mail.gmail.com>
	<57D04B47.1030805@oracle.com>
	<CA+kOe09N5AQfwWfo6o0h7NqKNsBd1ewvDbrOORRBDPrDV=7B8Q@mail.gmail.com>
	<57E31457.3010801@oracle.com>
	<17F9D73F-196D-44CC-BAFF-CD7648786BF7@oracle.com>
Message-ID: <812afde5-0a27-91b2-c548-c61655bd665a@oracle.com>

On 22/09/16 08:54, Chris Hegarty wrote:
> On 22 Sep 2016, at 00:14, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>>
>> Martin
>>
>> The source is available in the JDK 9 sandbox (http-client-branch) at
>> http://hg.openjdk.java.net/jdk9/sandbox/
>>
>> I think it has been updated to reflect the API as described below.
>
> Apologies, it has not been update yet. I will do it over the next day, or so, and
> post a note when it is done.

Done.

This was a little rushed. Further implementation clean up will
be necessary.

-Chris.

> -Chris.
>
>> Michael.
>>
>> On 21/09/2016, 14:14, Martin Buchholz wrote:
>>>
>>>
>>> On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>>>
>>> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>>>
>>> [2] http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html
>>>
>>> Could we have actual source code for experimentation by interested parties?
>

From felix.yang at oracle.com  Mon Sep 26 07:56:38 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Mon, 26 Sep 2016 15:56:38 +0800
Subject: RFR 8085575_8130657, misc fixes for a few of java.net intermittent
	failures
Message-ID: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>

Hi there,

     please review following patch to a few of java.net tests.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8085575

     https://bugs.openjdk.java.net/browse/JDK-8130657

Webrev:

http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/

Add retry for java/net/Socket/InheritHandle.java. Though it may be 
unable to resolve all BindException ( I suppose it is the nature of such 
close-reuse scenarios), it will be helpful to avoid failures from 
asynchronized close, which has been observed especially on Windows. Also 
some misc changes on other two tests.


Thanks,

Felix


From christoph.langer at sap.com  Mon Sep 26 08:15:19 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 26 Sep 2016 08:15:19 +0000
Subject: RFR 8085575_8130657, misc fixes for a few of java.net
	intermittent	failures
In-Reply-To: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
References: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
Message-ID: <3a9add0ac71c4f158cbd0f5eb46b84fc@DEWDFE13DE11.global.corp.sap>

Hi Felix,

looks ok to me, though I'm no reviewer.

One nit: test/java/net/MulticastSocket/TimeToLive.java, line 40, you could remove the ';' from the try statement.

Best regards
Christoph

> -----Original Message-----
> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Felix
> Yang
> Sent: Montag, 26. September 2016 09:57
> To: net-dev at openjdk.java.net
> Subject: RFR 8085575_8130657, misc fixes for a few of java.net intermittent
> failures
> 
> Hi there,
> 
>      please review following patch to a few of java.net tests.
> 
> Bug:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8085575
> 
>      https://bugs.openjdk.java.net/browse/JDK-8130657
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/
> 
> Add retry for java/net/Socket/InheritHandle.java. Though it may be
> unable to resolve all BindException ( I suppose it is the nature of such
> close-reuse scenarios), it will be helpful to avoid failures from
> asynchronized close, which has been observed especially on Windows. Also
> some misc changes on other two tests.
> 
> 
> Thanks,
> 
> Felix


From daniel.fuchs at oracle.com  Mon Sep 26 09:29:45 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 26 Sep 2016 10:29:45 +0100
Subject: RFR 8085575_8130657, misc fixes for a few of java.net
	intermittent failures
In-Reply-To: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
References: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
Message-ID: <c2e0f78d-9c78-dfda-dfee-87482b846a46@oracle.com>

Hi Felix,

InheritHandle.java:

   79         } finally {
   80             try {
   81                 ss.close();
   82             } catch (IOException e) {
   83                 e.printStackTrace();
   84             }
   85         }

Is finally the right construct here? It seems to me that
you're changing the logic of the test. I would expect the
socket to be closed only when an exception is received?

Otherwise you're going to close the socket again at
line 94

   94             ss.close();

which looks strange to me...

best regards,

-- daniel


On 26/09/16 08:56, Felix Yang wrote:
> Hi there,
>
>     please review following patch to a few of java.net tests.
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8085575
>
>     https://bugs.openjdk.java.net/browse/JDK-8130657
>
> Webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/
>
> Add retry for java/net/Socket/InheritHandle.java. Though it may be
> unable to resolve all BindException ( I suppose it is the nature of such
> close-reuse scenarios), it will be helpful to avoid failures from
> asynchronized close, which has been observed especially on Windows. Also
> some misc changes on other two tests.
>
>
> Thanks,
>
> Felix
>


From xuelei.fan at oracle.com  Mon Sep 26 09:57:50 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 26 Sep 2016 17:57:50 +0800
Subject: RFR 8085575_8130657, misc fixes for a few of java.net
	intermittent failures
In-Reply-To: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
References: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
Message-ID: <4fa6edba-0b7f-8327-13f0-b9c01cb8006d@oracle.com>

Just FYI.

The intermittent failures look like similar to some anti-free-port using 
issues.  In the current testing environment, for the InheritHandle test 
case, this anti-free-port using issue may looks like:

1. InheritHandle creates a server socket on a free port, and gets the 
port (PORT-A). (line 60-61)
2. InheritHandle close the server socket. (line 87)
3. Another test (TEST-B) creates a server socket on a free port. PORT-A 
may be used by the TEST-B.
4. InheritHandle create new server socket on PORT-A (line 88), it is 
expected to fail as PORT-A has been used by TEST-B.

The InheritHandle.java may run into intermittent failure unless it is 
run single alone.

Xuelei

On 9/26/2016 3:56 PM, Felix Yang wrote:
> Hi there,
>
>     please review following patch to a few of java.net tests.
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8085575
>
>     https://bugs.openjdk.java.net/browse/JDK-8130657
>
> Webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/
>
> Add retry for java/net/Socket/InheritHandle.java. Though it may be
> unable to resolve all BindException ( I suppose it is the nature of such
> close-reuse scenarios), it will be helpful to avoid failures from
> asynchronized close, which has been observed especially on Windows. Also
> some misc changes on other two tests.
>
>
> Thanks,
>
> Felix
>

From felix.yang at oracle.com  Mon Sep 26 13:47:38 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Mon, 26 Sep 2016 21:47:38 +0800
Subject: RFR 8085575_8130657, misc fixes for a few of java.net
	intermittent failures
In-Reply-To: <4fa6edba-0b7f-8327-13f0-b9c01cb8006d@oracle.com>
References: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
	<4fa6edba-0b7f-8327-13f0-b9c01cb8006d@oracle.com>
Message-ID: <A7F5391D-8A4F-48FB-8CFB-B0482C8A646C@oracle.com>

Xuelei,
    thanks for the information. That is why I stated it is the nature of such scenario. Some of such scenarios look like not avoidable.

Thanks,
Felix
> On 26 Sep 2016, at 5:57 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Just FYI.
> 
> The intermittent failures look like similar to some anti-free-port using issues.  In the current testing environment, for the InheritHandle test case, this anti-free-port using issue may looks like:
> 
> 1. InheritHandle creates a server socket on a free port, and gets the port (PORT-A). (line 60-61)
> 2. InheritHandle close the server socket. (line 87)
> 3. Another test (TEST-B) creates a server socket on a free port. PORT-A may be used by the TEST-B.
> 4. InheritHandle create new server socket on PORT-A (line 88), it is expected to fail as PORT-A has been used by TEST-B.
> 
> The InheritHandle.java may run into intermittent failure unless it is run single alone.
> 
> Xuelei
> 
> On 9/26/2016 3:56 PM, Felix Yang wrote:
>> Hi there,
>> 
>>    please review following patch to a few of java.net tests.
>> 
>> Bug:
>> 
>>    https://bugs.openjdk.java.net/browse/JDK-8085575
>> 
>>    https://bugs.openjdk.java.net/browse/JDK-8130657
>> 
>> Webrev:
>> 
>> http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/
>> 
>> Add retry for java/net/Socket/InheritHandle.java. Though it may be
>> unable to resolve all BindException ( I suppose it is the nature of such
>> close-reuse scenarios), it will be helpful to avoid failures from
>> asynchronized close, which has been observed especially on Windows. Also
>> some misc changes on other two tests.
>> 
>> 
>> Thanks,
>> 
>> Felix
>> 


From felix.yang at oracle.com  Mon Sep 26 14:02:58 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Mon, 26 Sep 2016 22:02:58 +0800
Subject: RFR 8085575_8130657, misc fixes for a few of java.net
	intermittent failures
In-Reply-To: <c2e0f78d-9c78-dfda-dfee-87482b846a46@oracle.com>
References: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
	<c2e0f78d-9c78-dfda-dfee-87482b846a46@oracle.com>
Message-ID: <AA107FF2-91CD-4197-859A-BAB43D407A9A@oracle.com>

Hi Daniel,
     thanks for figuring out this mistake. Put it before return to avoid unclosed socket. Also updated style as Langer suggested.

Updated web rev:
     http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.01/

Thanks,
Felix
> On 26 Sep 2016, at 5:29 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Felix,
> 
> InheritHandle.java:
> 
>  79         } finally {
>  80             try {
>  81                 ss.close();
>  82             } catch (IOException e) {
>  83                 e.printStackTrace();
>  84             }
>  85         }
> 
> Is finally the right construct here? It seems to me that
> you're changing the logic of the test. I would expect the
> socket to be closed only when an exception is received?
> 
> Otherwise you're going to close the socket again at
> line 94
> 
>  94             ss.close();
> 
> which looks strange to me...
> 
> best regards,
> 
> -- daniel
> 
> 
> On 26/09/16 08:56, Felix Yang wrote:
>> Hi there,
>> 
>>    please review following patch to a few of java.net tests.
>> 
>> Bug:
>> 
>>    https://bugs.openjdk.java.net/browse/JDK-8085575
>> 
>>    https://bugs.openjdk.java.net/browse/JDK-8130657
>> 
>> Webrev:
>> 
>> http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/
>> 
>> Add retry for java/net/Socket/InheritHandle.java. Though it may be
>> unable to resolve all BindException ( I suppose it is the nature of such
>> close-reuse scenarios), it will be helpful to avoid failures from
>> asynchronized close, which has been observed especially on Windows. Also
>> some misc changes on other two tests.
>> 
>> 
>> Thanks,
>> 
>> Felix
>> 
> 


From chris.hegarty at oracle.com  Mon Sep 26 14:50:48 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 26 Sep 2016 15:50:48 +0100
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
In-Reply-To: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
References: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
Message-ID: <3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>

Christoph,

On 22/09/16 21:59, Langer, Christoph wrote:
> Hi,
>
> while looking at utility functions for creating exceptions in
> libjava/libnet I found a small spot that should be consolidated right away.
>
>
> The function NET_ThrowSocketException does only exist in the windows
> native implementation and is only used in 3 places in
> SocketInputStream.c. I removed this in favor of directly calling
> JNU_ThrowByName as the Unix variant of that code already does.
>
>
> In that function Java_java_net_SocketInputStream_socketRead0 I also
> replaced throwing a SocketException with throwing an NPE in the rare
> case that a the JNI input for the file descriptor is null. That?s
> probably more natural and should virtually never occur anyways.

Hmmm... I'm not sure about this. SocketException is thrown on
unix too for a similar situation. More significantly, a null value
represents that the socket has been, possibly asynchronously,
closed.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/

Other than the above concern, the remainder of the code looks ok
to me.

-Chris.

From daniel.fuchs at oracle.com  Mon Sep 26 15:04:38 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 26 Sep 2016 16:04:38 +0100
Subject: RFR 8085575_8130657, misc fixes for a few of java.net
	intermittent failures
In-Reply-To: <AA107FF2-91CD-4197-859A-BAB43D407A9A@oracle.com>
References: <db0dd55c-1584-bb57-9416-04af4defdbc9@oracle.com>
	<c2e0f78d-9c78-dfda-dfee-87482b846a46@oracle.com>
	<AA107FF2-91CD-4197-859A-BAB43D407A9A@oracle.com>
Message-ID: <fef09b25-d02b-c5ff-a289-8034cc0c0c6a@oracle.com>

Hi Felix,

This looks good to me now.

best regards,

-- daniel

On 26/09/16 15:02, Felix Yang wrote:
> Hi Daniel,
>      thanks for figuring out this mistake. Put it before return to avoid unclosed socket. Also updated style as Langer suggested.
>
> Updated web rev:
>      http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.01/
>
> Thanks,
> Felix
>> On 26 Sep 2016, at 5:29 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Felix,
>>
>> InheritHandle.java:
>>
>>  79         } finally {
>>  80             try {
>>  81                 ss.close();
>>  82             } catch (IOException e) {
>>  83                 e.printStackTrace();
>>  84             }
>>  85         }
>>
>> Is finally the right construct here? It seems to me that
>> you're changing the logic of the test. I would expect the
>> socket to be closed only when an exception is received?
>>
>> Otherwise you're going to close the socket again at
>> line 94
>>
>>  94             ss.close();
>>
>> which looks strange to me...
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 26/09/16 08:56, Felix Yang wrote:
>>> Hi there,
>>>
>>>    please review following patch to a few of java.net tests.
>>>
>>> Bug:
>>>
>>>    https://bugs.openjdk.java.net/browse/JDK-8085575
>>>
>>>    https://bugs.openjdk.java.net/browse/JDK-8130657
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~xiaofeya/8085575_8130657/webrev.00/
>>>
>>> Add retry for java/net/Socket/InheritHandle.java. Though it may be
>>> unable to resolve all BindException ( I suppose it is the nature of such
>>> close-reuse scenarios), it will be helpful to avoid failures from
>>> asynchronized close, which has been observed especially on Windows. Also
>>> some misc changes on other two tests.
>>>
>>>
>>> Thanks,
>>>
>>> Felix
>>>
>>
>


From christoph.langer at sap.com  Mon Sep 26 17:58:47 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 26 Sep 2016 17:58:47 +0000
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
In-Reply-To: <3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>
References: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
	<3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>
Message-ID: <0e33d243428e422da2a9c80172d411d1@DEWDFE13DE11.global.corp.sap>

Hi Chris,

I agree with your comment on the NPE. It would probably be wrong. So I restored the old code and also removed the comments suggesting the NPE. Here is my new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.1/

What I was thinking a bit more about after I posted my initial webrev was the fact that the old NET_ThrowSocketException would register a GlobalRef to java/net/SocketException whereas the other, more generic code would always use the lookup by name. Would you think it is a performance benefit to keep a reference to a standard exception class in some place and use it for throwing or is it better to always look up the class? Throwing those kind of exceptions is probably not on the hot path anyway - but on the other hand it should be no issue to keep references to these very basic class types. What's your view on that?

And another probably aesthetic thing: I notice that sometimes a JNU_JAVANETPKG "SocketException" is used and sometimes a "java/net/SocketException", even within the same file like SocketInputStream.c. Maybe I should unify this in the files that I touch here and if yes, shall I use the literal name or the JNU_JAVANETPKG define? Any opinion on that?

Thanks for taking care of this,
Christoph


> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Montag, 26. September 2016 16:51
> To: Langer, Christoph <christoph.langer at sap.com>; net-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> NET_ThrowSocketException in windows libnet
> 
> Christoph,
> 
> On 22/09/16 21:59, Langer, Christoph wrote:
> > Hi,
> >
> > while looking at utility functions for creating exceptions in
> > libjava/libnet I found a small spot that should be consolidated right away.
> >
> >
> > The function NET_ThrowSocketException does only exist in the windows
> > native implementation and is only used in 3 places in
> > SocketInputStream.c. I removed this in favor of directly calling
> > JNU_ThrowByName as the Unix variant of that code already does.
> >
> >
> > In that function Java_java_net_SocketInputStream_socketRead0 I also
> > replaced throwing a SocketException with throwing an NPE in the rare
> > case that a the JNI input for the file descriptor is null. That's
> > probably more natural and should virtually never occur anyways.
> 
> Hmmm... I'm not sure about this. SocketException is thrown on
> unix too for a similar situation. More significantly, a null value
> represents that the socket has been, possibly asynchronously,
> closed.
> 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/
> 
> Other than the above concern, the remainder of the code looks ok
> to me.
> 
> -Chris.

From rob.mckenna at oracle.com  Mon Sep 26 23:09:22 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 27 Sep 2016 00:09:22 +0100
Subject: RFR - 8166747: Add invalid network / computer name cases to
	isReachable known failure switch
Message-ID: <20160926230922.GF3496@vimes>

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 this call when a host is not reachable. In these cases ping4() simply returns false as opposed to throwing an exception.

Prior releases of the JDK would return false when using the tcp ping method where we currently throw an exception with the ERROR_INVALID_COMPUTERNAME (Windows error code 1210) or ERROR_INVALID_NETNAME (1214) errors. We should add these cases to the switch statement for compatibility purposes.

http://cr.openjdk.java.net/~robm/8166747/webrev.01/

	-Rob

From mark.sheppard at oracle.com  Tue Sep 27 00:02:51 2016
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 27 Sep 2016 01:02:51 +0100
Subject: RFR - 8166747: Add invalid network / computer name cases to
	isReachable known failure switch
In-Reply-To: <20160926230922.GF3496@vimes>
References: <20160926230922.GF3496@vimes>
Message-ID: <0d628805-6428-7119-0f83-ca7f0e274df3@oracle.com>

Hi Rob,
     changes look reasonable ...
perhaps align the two additions below the existing ERROR_XXX set, all 
neat and tidy :-)

regards
Mark

On 27/09/2016 00:09, 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 this call when a host is not reachable. In these cases ping4() simply returns false as opposed to throwing an exception.
>
> Prior releases of the JDK would return false when using the tcp ping method where we currently throw an exception with the ERROR_INVALID_COMPUTERNAME (Windows error code 1210) or ERROR_INVALID_NETNAME (1214) errors. We should add these cases to the switch statement for compatibility purposes.
>
> http://cr.openjdk.java.net/~robm/8166747/webrev.01/
>
> 	-Rob


From felix.yang at oracle.com  Tue Sep 27 02:08:07 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 27 Sep 2016 10:08:07 +0800
Subject: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails
	intermittently with error while cleaning up threads after test
Message-ID: <316073be-86f4-296e-01a6-324d69804129@oracle.com>

Hi all,

     please review following test fix.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8154525

Webrev:

     http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/

This test has been observed to fail sometimes with "Error while cleaning 
up threads after test ", even after test complete message printed. 
Updated it to run with othervm mode.

Thanks,

Felix



From chris.hegarty at oracle.com  Tue Sep 27 07:55:21 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Sep 2016 08:55:21 +0100
Subject: RFR 8154525,
	java/net/ServerSocket/ThreadStop.java fails intermittently with error
	while cleaning up threads after test
In-Reply-To: <316073be-86f4-296e-01a6-324d69804129@oracle.com>
References: <316073be-86f4-296e-01a6-324d69804129@oracle.com>
Message-ID: <C943F795-DE8B-47F2-AFFB-F685ABFA0747@oracle.com>


> On 27 Sep 2016, at 03:08, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Hi all,
> 
>    please review following test fix.
> 
> Bug:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8154525
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/
> 
> This test has been observed to fail sometimes with "Error while cleaning up threads after test ", even after test complete message printed. Updated it to run with othervm mode.

I think this is fine. Additionally, should the main thread wait/join 
the ?Server? thread before exiting, to ensure that it is complete
before the test returns ( this would eliminate any potential race
while cleaning up ).

-Chris.

From chris.hegarty at oracle.com  Tue Sep 27 07:56:30 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Sep 2016 08:56:30 +0100
Subject: RFR - 8166747: Add invalid network / computer name cases to
	isReachable known failure switch
In-Reply-To: <0d628805-6428-7119-0f83-ca7f0e274df3@oracle.com>
References: <20160926230922.GF3496@vimes>
	<0d628805-6428-7119-0f83-ca7f0e274df3@oracle.com>
Message-ID: <2E7A7AB0-AE69-4AF9-A135-FCD50C1BCA3A@oracle.com>

On 27 Sep 2016, at 01:02, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> Hi Rob,
>    changes look reasonable ?

+1

> perhaps align the two additions below the existing ERROR_XXX set, all neat and tidy :-)

+1

-Chris.

> regards
> Mark
> 
> On 27/09/2016 00:09, 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 this call when a host is not reachable. In these cases ping4() simply returns false as opposed to throwing an exception.
>> 
>> Prior releases of the JDK would return false when using the tcp ping method where we currently throw an exception with the ERROR_INVALID_COMPUTERNAME (Windows error code 1210) or ERROR_INVALID_NETNAME (1214) errors. We should add these cases to the switch statement for compatibility purposes.
>> 
>> http://cr.openjdk.java.net/~robm/8166747/webrev.01/
>> 
>> 	-Rob
> 


From chris.hegarty at oracle.com  Tue Sep 27 08:09:40 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Sep 2016 09:09:40 +0100
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
In-Reply-To: <0e33d243428e422da2a9c80172d411d1@DEWDFE13DE11.global.corp.sap>
References: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
	<3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>
	<0e33d243428e422da2a9c80172d411d1@DEWDFE13DE11.global.corp.sap>
Message-ID: <6707B730-8A1B-4616-8E25-129079D67156@oracle.com>

Christoph,

On 26 Sep 2016, at 18:58, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Chris,
> 
> I agree with your comment on the NPE. It would probably be wrong. So I restored the old code and also removed the comments suggesting the NPE. Here is my new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.1/

This looks fine.

> What I was thinking a bit more about after I posted my initial webrev was the fact that the old NET_ThrowSocketException would register a GlobalRef to java/net/SocketException whereas the other, more generic code would always use the lookup by name. Would you think it is a performance benefit to keep a reference to a standard exception class in some place and use it for throwing or is it better to always look up the class? Throwing those kind of exceptions is probably not on the hot path anyway - but on the other hand it should be no issue to keep references to these very basic class types. What's your view on that?

I don?t believe that using a GlobalRef is worth it here. It adds a little
complication, while not offering much benefit. JNU_ThrowByName
should be fine.

> And another probably aesthetic thing: I notice that sometimes a JNU_JAVANETPKG "SocketException" is used and sometimes a "java/net/SocketException", even within the same file like SocketInputStream.c. Maybe I should unify this in the files that I touch here and if yes, shall I use the literal name or the JNU_JAVANETPKG define? Any opinion on that?

My preference is to remove JNU_JAVANETPKG, and just use "java/net/?.

-Chris

> Thanks for taking care of this,
> Christoph
> 
> 
>> -----Original Message-----
>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> Sent: Montag, 26. September 2016 16:51
>> To: Langer, Christoph <christoph.langer at sap.com>; net-dev at openjdk.java.net
>> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
>> NET_ThrowSocketException in windows libnet
>> 
>> Christoph,
>> 
>> On 22/09/16 21:59, Langer, Christoph wrote:
>>> Hi,
>>> 
>>> while looking at utility functions for creating exceptions in
>>> libjava/libnet I found a small spot that should be consolidated right away.
>>> 
>>> 
>>> The function NET_ThrowSocketException does only exist in the windows
>>> native implementation and is only used in 3 places in
>>> SocketInputStream.c. I removed this in favor of directly calling
>>> JNU_ThrowByName as the Unix variant of that code already does.
>>> 
>>> 
>>> In that function Java_java_net_SocketInputStream_socketRead0 I also
>>> replaced throwing a SocketException with throwing an NPE in the rare
>>> case that a the JNI input for the file descriptor is null. That's
>>> probably more natural and should virtually never occur anyways.
>> 
>> Hmmm... I'm not sure about this. SocketException is thrown on
>> unix too for a similar situation. More significantly, a null value
>> represents that the socket has been, possibly asynchronously,
>> closed.
>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
>>> 
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/
>> 
>> Other than the above concern, the remainder of the code looks ok
>> to me.
>> 
>> -Chris.


From felix.yang at oracle.com  Tue Sep 27 08:25:15 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 27 Sep 2016 16:25:15 +0800
Subject: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails
	intermittently with error while cleaning up threads after test
In-Reply-To: <C943F795-DE8B-47F2-AFFB-F685ABFA0747@oracle.com>
References: <316073be-86f4-296e-01a6-324d69804129@oracle.com>
	<C943F795-DE8B-47F2-AFFB-F685ABFA0747@oracle.com>
Message-ID: <98f654da-ccd7-6e71-6ecb-114e204b7d42@oracle.com>

Hi Chris,

     updated as suggested

http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.01/

Thanks,
Felix
On 2016/9/27 15:55, Chris Hegarty wrote:
>> On 27 Sep 2016, at 03:08, Felix Yang <felix.yang at oracle.com> wrote:
>>
>> Hi all,
>>
>>     please review following test fix.
>>
>> Bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8154525
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/
>>
>> This test has been observed to fail sometimes with "Error while cleaning up threads after test ", even after test complete message printed. Updated it to run with othervm mode.
> I think this is fine. Additionally, should the main thread wait/join
> the ?Server? thread before exiting, to ensure that it is complete
> before the test returns ( this would eliminate any potential race
> while cleaning up ).
>
> -Chris.


From chris.hegarty at oracle.com  Tue Sep 27 08:29:29 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Sep 2016 09:29:29 +0100
Subject: RFR 8154525,
	java/net/ServerSocket/ThreadStop.java fails intermittently with error
	while cleaning up threads after test
In-Reply-To: <98f654da-ccd7-6e71-6ecb-114e204b7d42@oracle.com>
References: <316073be-86f4-296e-01a6-324d69804129@oracle.com>
	<C943F795-DE8B-47F2-AFFB-F685ABFA0747@oracle.com>
	<98f654da-ccd7-6e71-6ecb-114e204b7d42@oracle.com>
Message-ID: <4D42BC32-315F-4E02-B166-2C2A3D4E6129@oracle.com>

On 27 Sep 2016, at 09:25, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Hi Chris,
> 
>    updated as suggested
> 
> http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.01/

Looks good to me.

Up to you, but with the thread join ( if my hunch is correct ) we may not
actually need othervm, but of course it should be fine with it too.

-Chris.

> Thanks,
> Felix
> On 2016/9/27 15:55, Chris Hegarty wrote:
>>> On 27 Sep 2016, at 03:08, Felix Yang <felix.yang at oracle.com> wrote:
>>> 
>>> Hi all,
>>> 
>>>    please review following test fix.
>>> 
>>> Bug:
>>> 
>>>    https://bugs.openjdk.java.net/browse/JDK-8154525
>>> 
>>> Webrev:
>>> 
>>>    http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/
>>> 
>>> This test has been observed to fail sometimes with "Error while cleaning up threads after test ", even after test complete message printed. Updated it to run with othervm mode.
>> I think this is fine. Additionally, should the main thread wait/join
>> the ?Server? thread before exiting, to ensure that it is complete
>> before the test returns ( this would eliminate any potential race
>> while cleaning up ).
>> 
>> -Chris.
> 


From felix.yang at oracle.com  Tue Sep 27 08:35:46 2016
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 27 Sep 2016 16:35:46 +0800
Subject: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails
	intermittently with error while cleaning up threads after test
In-Reply-To: <4D42BC32-315F-4E02-B166-2C2A3D4E6129@oracle.com>
References: <316073be-86f4-296e-01a6-324d69804129@oracle.com>
	<C943F795-DE8B-47F2-AFFB-F685ABFA0747@oracle.com>
	<98f654da-ccd7-6e71-6ecb-114e204b7d42@oracle.com>
	<4D42BC32-315F-4E02-B166-2C2A3D4E6129@oracle.com>
Message-ID: <07acd6a6-2e52-1f53-0a15-d23e10ae0542@oracle.com>

Chris,

     I will push without othervm

-Felix
On 2016/9/27 16:29, Chris Hegarty wrote:
> On 27 Sep 2016, at 09:25, Felix Yang <felix.yang at oracle.com> wrote:
>> Hi Chris,
>>
>>     updated as suggested
>>
>> http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.01/
> Looks good to me.
>
> Up to you, but with the thread join ( if my hunch is correct ) we may not
> actually need othervm, but of course it should be fine with it too.
>
> -Chris.
>
>> Thanks,
>> Felix
>> On 2016/9/27 15:55, Chris Hegarty wrote:
>>>> On 27 Sep 2016, at 03:08, Felix Yang <felix.yang at oracle.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>     please review following test fix.
>>>>
>>>> Bug:
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8154525
>>>>
>>>> Webrev:
>>>>
>>>>     http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/
>>>>
>>>> This test has been observed to fail sometimes with "Error while cleaning up threads after test ", even after test complete message printed. Updated it to run with othervm mode.
>>> I think this is fine. Additionally, should the main thread wait/join
>>> the ?Server? thread before exiting, to ensure that it is complete
>>> before the test returns ( this would eliminate any potential race
>>> while cleaning up ).
>>>
>>> -Chris.


From chris.hegarty at oracle.com  Tue Sep 27 08:38:50 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Sep 2016 09:38:50 +0100
Subject: RFR 8154525,
	java/net/ServerSocket/ThreadStop.java fails intermittently with error
	while cleaning up threads after test
In-Reply-To: <07acd6a6-2e52-1f53-0a15-d23e10ae0542@oracle.com>
References: <316073be-86f4-296e-01a6-324d69804129@oracle.com>
	<C943F795-DE8B-47F2-AFFB-F685ABFA0747@oracle.com>
	<98f654da-ccd7-6e71-6ecb-114e204b7d42@oracle.com>
	<4D42BC32-315F-4E02-B166-2C2A3D4E6129@oracle.com>
	<07acd6a6-2e52-1f53-0a15-d23e10ae0542@oracle.com>
Message-ID: <497E5EEA-D83E-4F9D-AA62-458AFD85E880@oracle.com>

On 27 Sep 2016, at 09:35, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Chris,
> 
>    I will push without othervm

Thanks. If we see future issues with this test, then we can add it back.

-Chris.

> -Felix
> On 2016/9/27 16:29, Chris Hegarty wrote:
>> On 27 Sep 2016, at 09:25, Felix Yang <felix.yang at oracle.com> wrote:
>>> Hi Chris,
>>> 
>>>    updated as suggested
>>> 
>>> http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.01/
>> Looks good to me.
>> 
>> Up to you, but with the thread join ( if my hunch is correct ) we may not
>> actually need othervm, but of course it should be fine with it too.
>> 
>> -Chris.
>> 
>>> Thanks,
>>> Felix
>>> On 2016/9/27 15:55, Chris Hegarty wrote:
>>>>> On 27 Sep 2016, at 03:08, Felix Yang <felix.yang at oracle.com> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>>    please review following test fix.
>>>>> 
>>>>> Bug:
>>>>> 
>>>>>    https://bugs.openjdk.java.net/browse/JDK-8154525
>>>>> 
>>>>> Webrev:
>>>>> 
>>>>>    http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/
>>>>> 
>>>>> This test has been observed to fail sometimes with "Error while cleaning up threads after test ", even after test complete message printed. Updated it to run with othervm mode.
>>>> I think this is fine. Additionally, should the main thread wait/join
>>>> the ?Server? thread before exiting, to ensure that it is complete
>>>> before the test returns ( this would eliminate any potential race
>>>> while cleaning up ).
>>>> 
>>>> -Chris.
> 


From sergei.kovalev at oracle.com  Tue Sep 27 15:44:10 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Tue, 27 Sep 2016 18:44:10 +0300
Subject: RFR(s): 8166791: Fix module dependencies for networking component
	tests
Message-ID: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com>

Hi team,

Could you please review small fix for regression tests.

BugID: https://bugs.openjdk.java.net/browse/JDK-8166791
WebRev: http://cr.openjdk.java.net/~skovalev/8166791/webrev.00/

Issue: Severl network related tests failed in case of using 
"--limit-modules java.base" command line option.

The test java/net/httpclient/http2/ErrorTest.java should declare 
dependencies on 'jdk.security.auth' module.

java/net/httpclient/security/Driver.java should depend oh 
'java.httpclient' and 'jdk.httpserver'.

java/net/spi/URLStreamHandlerProvider/Basic.java and 
sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java have 
declaration of dependency on 'java.compiler' but should be 'jdk.compiler'.

 From the test java/net/httpclient/http2/HpackDriver.java extracted one 
part that depends on 'jdk.localedata': 
java/net/httpclient/http2/HpackDriverHeaderTable.java because other part 
don't have any extra dependencies and could be executed in general case.

-- 
With best regards,
Sergei


From christoph.langer at sap.com  Tue Sep 27 18:56:26 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 27 Sep 2016 18:56:26 +0000
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
In-Reply-To: <6707B730-8A1B-4616-8E25-129079D67156@oracle.com>
References: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
	<3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>
	<0e33d243428e422da2a9c80172d411d1@DEWDFE13DE11.global.corp.sap>
	<6707B730-8A1B-4616-8E25-129079D67156@oracle.com>
Message-ID: <a3cd2afa8d43420b9e350c33de875526@DEWDFE13DE11.global.corp.sap>

Chris,

thanks for your input.

If there's no objections I'd push it like this later tomorrow:
http://cr.openjdk.java.net/~clanger/webrevs/8166584.2/

I've replaced the JNU_JAVANETPKG and JNU_JAVAIOPKG macros with the full exception class names.

Best regards
Christoph

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Dienstag, 27. September 2016 10:10
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> NET_ThrowSocketException in windows libnet
> 
> Christoph,
> 
> On 26 Sep 2016, at 18:58, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> >
> > Hi Chris,
> >
> > I agree with your comment on the NPE. It would probably be wrong. So I
> restored the old code and also removed the comments suggesting the NPE.
> Here is my new webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8166584.1/
> 
> This looks fine.
> 
> > What I was thinking a bit more about after I posted my initial webrev was the
> fact that the old NET_ThrowSocketException would register a GlobalRef to
> java/net/SocketException whereas the other, more generic code would always
> use the lookup by name. Would you think it is a performance benefit to keep a
> reference to a standard exception class in some place and use it for throwing
> or is it better to always look up the class? Throwing those kind of exceptions is
> probably not on the hot path anyway - but on the other hand it should be no
> issue to keep references to these very basic class types. What's your view on
> that?
> 
> I don?t believe that using a GlobalRef is worth it here. It adds a little
> complication, while not offering much benefit. JNU_ThrowByName
> should be fine.
> 
> > And another probably aesthetic thing: I notice that sometimes a
> JNU_JAVANETPKG "SocketException" is used and sometimes a
> "java/net/SocketException", even within the same file like SocketInputStream.c.
> Maybe I should unify this in the files that I touch here and if yes, shall I use the
> literal name or the JNU_JAVANETPKG define? Any opinion on that?
> 
> My preference is to remove JNU_JAVANETPKG, and just use "java/net/?.
> 
> -Chris
> 
> > Thanks for taking care of this,
> > Christoph
> >
> >
> >> -----Original Message-----
> >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >> Sent: Montag, 26. September 2016 16:51
> >> To: Langer, Christoph <christoph.langer at sap.com>; net-
> dev at openjdk.java.net
> >> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> >> NET_ThrowSocketException in windows libnet
> >>
> >> Christoph,
> >>
> >> On 22/09/16 21:59, Langer, Christoph wrote:
> >>> Hi,
> >>>
> >>> while looking at utility functions for creating exceptions in
> >>> libjava/libnet I found a small spot that should be consolidated right away.
> >>>
> >>>
> >>> The function NET_ThrowSocketException does only exist in the windows
> >>> native implementation and is only used in 3 places in
> >>> SocketInputStream.c. I removed this in favor of directly calling
> >>> JNU_ThrowByName as the Unix variant of that code already does.
> >>>
> >>>
> >>> In that function Java_java_net_SocketInputStream_socketRead0 I also
> >>> replaced throwing a SocketException with throwing an NPE in the rare
> >>> case that a the JNI input for the file descriptor is null. That's
> >>> probably more natural and should virtually never occur anyways.
> >>
> >> Hmmm... I'm not sure about this. SocketException is thrown on
> >> unix too for a similar situation. More significantly, a null value
> >> represents that the socket has been, possibly asynchronously,
> >> closed.
> >>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/
> >>
> >> Other than the above concern, the remainder of the code looks ok
> >> to me.
> >>
> >> -Chris.


From chris.hegarty at oracle.com  Tue Sep 27 19:24:11 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Sep 2016 20:24:11 +0100
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
In-Reply-To: <a3cd2afa8d43420b9e350c33de875526@DEWDFE13DE11.global.corp.sap>
References: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
	<3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>
	<0e33d243428e422da2a9c80172d411d1@DEWDFE13DE11.global.corp.sap>
	<6707B730-8A1B-4616-8E25-129079D67156@oracle.com>
	<a3cd2afa8d43420b9e350c33de875526@DEWDFE13DE11.global.corp.sap>
Message-ID: <683D7081-31B5-4C76-A339-614072712D49@oracle.com>


> On 27 Sep 2016, at 19:56, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Chris,
> 
> thanks for your input.
> 
> If there's no objections I'd push it like this later tomorrow:
> http://cr.openjdk.java.net/~clanger/webrevs/8166584.2/

Looks ok to me Christoph.

Thanks,
-Chris.

> I've replaced the JNU_JAVANETPKG and JNU_JAVAIOPKG macros with the full exception class names.
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> Sent: Dienstag, 27. September 2016 10:10
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: net-dev at openjdk.java.net
>> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
>> NET_ThrowSocketException in windows libnet
>> 
>> Christoph,
>> 
>> On 26 Sep 2016, at 18:58, Langer, Christoph <christoph.langer at sap.com>
>> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> I agree with your comment on the NPE. It would probably be wrong. So I
>> restored the old code and also removed the comments suggesting the NPE.
>> Here is my new webrev:
>> http://cr.openjdk.java.net/~clanger/webrevs/8166584.1/
>> 
>> This looks fine.
>> 
>>> What I was thinking a bit more about after I posted my initial webrev was the
>> fact that the old NET_ThrowSocketException would register a GlobalRef to
>> java/net/SocketException whereas the other, more generic code would always
>> use the lookup by name. Would you think it is a performance benefit to keep a
>> reference to a standard exception class in some place and use it for throwing
>> or is it better to always look up the class? Throwing those kind of exceptions is
>> probably not on the hot path anyway - but on the other hand it should be no
>> issue to keep references to these very basic class types. What's your view on
>> that?
>> 
>> I don?t believe that using a GlobalRef is worth it here. It adds a little
>> complication, while not offering much benefit. JNU_ThrowByName
>> should be fine.
>> 
>>> And another probably aesthetic thing: I notice that sometimes a
>> JNU_JAVANETPKG "SocketException" is used and sometimes a
>> "java/net/SocketException", even within the same file like SocketInputStream.c.
>> Maybe I should unify this in the files that I touch here and if yes, shall I use the
>> literal name or the JNU_JAVANETPKG define? Any opinion on that?
>> 
>> My preference is to remove JNU_JAVANETPKG, and just use "java/net/?.
>> 
>> -Chris
>> 
>>> Thanks for taking care of this,
>>> Christoph
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>>>> Sent: Montag, 26. September 2016 16:51
>>>> To: Langer, Christoph <christoph.langer at sap.com>; net-
>> dev at openjdk.java.net
>>>> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
>>>> NET_ThrowSocketException in windows libnet
>>>> 
>>>> Christoph,
>>>> 
>>>> On 22/09/16 21:59, Langer, Christoph wrote:
>>>>> Hi,
>>>>> 
>>>>> while looking at utility functions for creating exceptions in
>>>>> libjava/libnet I found a small spot that should be consolidated right away.
>>>>> 
>>>>> 
>>>>> The function NET_ThrowSocketException does only exist in the windows
>>>>> native implementation and is only used in 3 places in
>>>>> SocketInputStream.c. I removed this in favor of directly calling
>>>>> JNU_ThrowByName as the Unix variant of that code already does.
>>>>> 
>>>>> 
>>>>> In that function Java_java_net_SocketInputStream_socketRead0 I also
>>>>> replaced throwing a SocketException with throwing an NPE in the rare
>>>>> case that a the JNI input for the file descriptor is null. That's
>>>>> probably more natural and should virtually never occur anyways.
>>>> 
>>>> Hmmm... I'm not sure about this. SocketException is thrown on
>>>> unix too for a similar situation. More significantly, a null value
>>>> represents that the socket has been, possibly asynchronously,
>>>> closed.
>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/
>>>> 
>>>> Other than the above concern, the remainder of the code looks ok
>>>> to me.
>>>> 
>>>> -Chris.
> 


From vyom.tewari at oracle.com  Wed Sep 28 08:25:55 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 28 Sep 2016 13:55:55 +0530
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
	<2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
Message-ID: <850bd3be-1917-a697-8298-c26da68a0065@oracle.com>

Hi All,

I had off line discussion here at Oracle and we decided  not to override 
getReuseAddr/setReuseAddr for MulticastSocket. If user wants, he can set 
the SO_REUSEPORT with "setOption"before bind.

For MulticastSocket SO_REUSEADDR&SO_REUSEPORT are semantically 
equivalent which means either option will be sufficient to indicate that 
the address&port is reusable. So setting SO_REUSEPORT in constructor is 
really necessary/required ?

I am looking some comments on this from Intel people(they are in mail 
chain) who did this original change, before we decide how we wants to 
proceed on this issue.

Thanks,

Vyom


On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote:
> On 14/09/16 15:53, Mark Sheppard wrote:
>>
>> that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the
>> same could have been argued for the original
>> invocation of setReuseAddress, by default , in the constructors, which
>> is encapsulating, what pereceived as, common or defacto
>> practice wrt applying SO_REUSEADDR on mcast sockets at the system level.
>> As I understand it, it is generally perceived that SO_REUSEADDR and
>> SO_REUSEPORT are semantically equivalent for multicast sockets.
>> As such, I think in the case of MulticastSocket, the fact that the
>> setRuseAddress() is called in the constructor, it is appropriate
>> to set SO_REUSEPORT also when it exists in the OS.
>>
>> I take your point on the semantics of setReuseAddress in DatagramSocket
>> as per its spec. The spec does allude to MulticastSocket.
>> As such, the current proposal's changes just lack the appropriate
>> javadoc to describe its behavior, and its additional functionality of
>> setting SO_REUSEPORT.
>> It is not necessary that overridden method should mirror the semantics
>> of the base class method.
>> If it is accepted that it is generally perceived that SO_REUSEADDR and
>> SO_REUSEPORT are semantically equivalent for multicast sockets,
>> then it seems appropriate that an overriding setReuseAddress(..) method
>> in MulticastSocket can reflect this.
>
> That sounds reasonable.
>
> -Chris.
>
>> regards
>> Mark
>>
>>
>>
>> On 14/09/2016 14:58, Chris Hegarty wrote:
>>> One additional remark.
>>>
>>> Was it appropriate to update the legacy MC constructors
>>> to set the new JDK 9 SO_REUSEPORT in the first place?
>>> This can be achievable, opt-in from new code, by creating
>>> an unbound MS, setting the option, then binding.
>>>
>>> -Chris.
>>>
>>> On 14/09/16 14:47, Chris Hegarty wrote:
>>>> Mark,
>>>>
>>>> On 14/09/16 14:22, Mark Sheppard wrote:
>>>>>
>>>>> Hi Chris,
>>>>>      I don't fully understand your objections to the approach taken.
>>>>> Is there a compatibility issue with the addition of the additional
>>>>> methods to MulticastSocket?
>>>>
>>>> The concern is with setReuseAddress performing an operation that
>>>> is not clear from the method specification, e.g. from 
>>>> setReuseAddress()
>>>>
>>>>      * Enable/disable the SO_REUSEADDR socket option.
>>>>
>>>> This is no longer accurate. The proposed changes would affect
>>>> SO_REUSEPORT too.
>>>>
>>>>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
>>>>> option, this has to be done explicitly via setOption at this level of
>>>>> abstraction.
>>>>
>>>> Yes, it is a bit odd, but these are legacy classes. I am not opposed
>>>> to adding a new method for this, or something else. I just want to
>>>> avoid future issues and confusion when setReuseAddress is called and
>>>> then it is noticed that, the somewhat orthogonal option, 
>>>> SO_REUSEPORT's
>>>> value has changed. setReuseAddress's spec is very clear about what it
>>>> does.
>>>>
>>>>> MulticastSocket is a subclass of DatagramSocket (that in itself is a
>>>>> questionable structuring), and as such
>>>>> has specialized behaviour, and part  of that specialization is the
>>>>> setting of  the setting SO_REUSEADDR and SO_REUSEPORT
>>>>> in its constructors, to enable address reuse semantics, prior to
>>>>> binding
>>>>> an address.
>>>>
>>>> Understood. Of course, the setting of SO_REUSEPORT is new in 9,
>>>> hence the problem.
>>>>
>>>>> As part of that specialization, it would seem appropriate that
>>>>> MulticastSocket manipulate the SO_REUSEPORT
>>>>> option in a consistent way. Adding an overridden setReuseAddress(...)
>>>>> method provides that consistency and
>>>>> encapsulates the specialized behaviour.
>>>>
>>>> I agree with the abstraction, just not that setReuseAddress should
>>>> be used to achieve it. The name and spec of this method is so
>>>> tied to SO_REUSEADDR.
>>>>
>>>>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT
>>>>> document clearly how to handle the failing scenario, that an
>>>>> MulticastSocket
>>>>> requires both setReuseAddress() and a setOption call to disable
>>>>> reuseaddress semantics on an unbound MulticastSocket ?
>>>>
>>>> That is one option, and the option that I was suggesting as a possible
>>>> alternative.
>>>>
>>>>> This then raises the question of why have a convenience method, 
>>>>> such as
>>>>> setReuseAddress() in the first place, when it can be handled
>>>>> adequately via the setOption
>>>>
>>>> We are moving away from these option specific getter and setter
>>>> methods, in favor of the more general get/setOption methods, as
>>>> the latter are more adaptable.
>>>>
>>>> If setReuseAddress is to operate on more than SO_REUSEADDR, then
>>>> its spec should be very clear about this.
>>>>
>>>> -Chris.
>>>>
>>>>
>>>>> regards
>>>>> Mark
>>>>>
>>>>> On 14/09/2016 13:34, Chris Hegarty wrote:
>>>>>> Mark,
>>>>>>
>>>>>> On 14/09/16 13:23, Mark Sheppard wrote:
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>     so are you accepting that it is correct to add the overridden
>>>>>>> methods in MulticastSocket and that these need
>>>>>>> appropriate javadoc ?
>>>>>>
>>>>>> I think we need these, but they should just call their super
>>>>>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
>>>>>> exist solely as a place to locate guidance, or a note, that one
>>>>>> will likely want to set SO_REUSEPORT too.
>>>>>>
>>>>>>> or are you advocating pushing the handing of the SO_REUSEPORT into
>>>>>>> the
>>>>>>> base DatagramSocket class ?
>>>>>>
>>>>>> It is already there. I am not proposing to change this.
>>>>>>
>>>>>>> It is not clear how your code changes fit in the proposed fix i.e.
>>>>>>> the
>>>>>>> explicit setting of the option to false?
>>>>>>
>>>>>> My proposal is an alternative. It is not related to the current
>>>>>> webrev.
>>>>>>
>>>>>>> With the current proposed changes then I think it would be
>>>>>>> sufficient to
>>>>>>> invoke setReuseAddress(true) in MulticastSocket constructors
>>>>>>> rather than
>>>>>>>
>>>>>>>         // Enable SO_REUSEADDR before binding
>>>>>>>         setReuseAddress
>>>>>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*); 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>         // Enable SO_REUSEPORT if supported before binding
>>>>>>>         *if* (supportedOptions
>>>>>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> {
>>>>>>>             *this*.setOption
>>>>>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>, 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *true*);
>>>>>>>         }
>>>>>>>
>>>>>>>
>>>>>>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>>>>>>
>>>>>> Yes, this is what Vyom has proposed, in the webrev.
>>>>>>
>>>>>> I would like to explore an alternative, so see what it would look
>>>>>> like.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>
>>>>>>> regards
>>>>>>> Mark
>>>>>>>
>>>>>>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>>>>>>> Vyom,
>>>>>>>>
>>>>>>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review the below code change.
>>>>>>>>>
>>>>>>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>>>>>>
>>>>>>>>> Webrev  :
>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This change override the "get/setReuseAddress" for 
>>>>>>>>> MulticaseSocket
>>>>>>>>> and
>>>>>>>>> will abstract with both reuse attributes(SO_REUSEADDR &
>>>>>>>>> SO_REUSEPORT).
>>>>>>>>
>>>>>>>> This issue arises since the changes for 6432031 "Add support for
>>>>>>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>>>>>>> the available. So setting setReuseAddress(false) alone is no 
>>>>>>>> longer
>>>>>>>> sufficient to disable address/port reuse, one must also set
>>>>>>>> SO_REUSEPORT to false.
>>>>>>>>
>>>>>>>> I would be really nervous about changing set/getReuseAddress,
>>>>>>>> without
>>>>>>>> at least updating the javadoc to indicate that it is now, for MS,
>>>>>>>> operating on two socket options.  Although, I do have sympathy
>>>>>>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>>>>>>> dealing with multicasting.
>>>>>>>>
>>>>>>>> An alternative, maybe; Since the MS constructors document that
>>>>>>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>>>>>>> on the set/getReuseAddress methods would be sufficient, that
>>>>>>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>>>>>>> to be set to have the desired effect?
>>>>>>>>
>>>>>>>> If so, then code would have to:
>>>>>>>>
>>>>>>>>     setReuseAddress(false);
>>>>>>>>
>>>>>>>>     if
>>>>>>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>>>>>> this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>>>>>>
>>>>>>>>   , but at least it is explicit.
>>>>>>>>
>>>>>>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>>>>>>> they should, right? This seems to have slipped past during 6432031
>>>>>>>> [1].
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>>>>>
>>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160928/8afe46c6/attachment-0001.html>

From chris.hegarty at oracle.com  Wed Sep 28 09:12:57 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 28 Sep 2016 10:12:57 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
	<2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
	<850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
Message-ID: <4460f8ed-8ece-7bca-b444-9f39519e16b9@oracle.com>

Thanks Vyom,

On 28/09/16 09:25, Vyom Tewari wrote:
> Hi All,
>
> I had off line discussion here at Oracle and we decided  not to override
> getReuseAddr/setReuseAddr for MulticastSocket. If user wants, he can set
> the SO_REUSEPORT with "setOption"before bind.

Right. All options that we looked at seem less than satisfactory
( these getter/setter methods work at a single socket option level ).

> For MulticastSocket SO_REUSEADDR&SO_REUSEPORT are semantically
> equivalent which means either option will be sufficient to indicate that
> the address&port is reusable. So setting SO_REUSEPORT in constructor is
> really necessary/required ?

This is the crux of the issue. I have been unable to find the
reasoning behind this particular part of the change for 6432031
[1]. As you correctly say, SO_REUSEADDR and SO_REUSEPORT are
semantically equivalent for multicasting.

> I am looking some comments on this from Intel people(they are in mail
> chain) who did this original change, before we decide how we wants to
> proceed on this issue.

At this point, without further clarification of why SO_REUSEPORT
was added to the MulticastSocket constructor, my preference is
to revert it.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-6432031

> Thanks,
>
> Vyom
>
>
> On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote:
>> On 14/09/16 15:53, Mark Sheppard wrote:
>>>
>>> that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the
>>> same could have been argued for the original
>>> invocation of setReuseAddress, by default , in the constructors, which
>>> is encapsulating, what pereceived as, common or defacto
>>> practice wrt applying SO_REUSEADDR on mcast sockets at the system level.
>>> As I understand it, it is generally perceived that SO_REUSEADDR and
>>> SO_REUSEPORT are semantically equivalent for multicast sockets.
>>> As such, I think in the case of MulticastSocket, the fact that the
>>> setRuseAddress() is called in the constructor, it is appropriate
>>> to set SO_REUSEPORT also when it exists in the OS.
>>>
>>> I take your point on the semantics of setReuseAddress in DatagramSocket
>>> as per its spec. The spec does allude to MulticastSocket.
>>> As such, the current proposal's changes just lack the appropriate
>>> javadoc to describe its behavior, and its additional functionality of
>>> setting SO_REUSEPORT.
>>> It is not necessary that overridden method should mirror the semantics
>>> of the base class method.
>>> If it is accepted that it is generally perceived that SO_REUSEADDR and
>>> SO_REUSEPORT are semantically equivalent for multicast sockets,
>>> then it seems appropriate that an overriding setReuseAddress(..) method
>>> in MulticastSocket can reflect this.
>>
>> That sounds reasonable.
>>
>> -Chris.
>>
>>> regards
>>> Mark
>>>
>>>
>>>
>>> On 14/09/2016 14:58, Chris Hegarty wrote:
>>>> One additional remark.
>>>>
>>>> Was it appropriate to update the legacy MC constructors
>>>> to set the new JDK 9 SO_REUSEPORT in the first place?
>>>> This can be achievable, opt-in from new code, by creating
>>>> an unbound MS, setting the option, then binding.
>>>>
>>>> -Chris.
>>>>
>>>> On 14/09/16 14:47, Chris Hegarty wrote:
>>>>> Mark,
>>>>>
>>>>> On 14/09/16 14:22, Mark Sheppard wrote:
>>>>>>
>>>>>> Hi Chris,
>>>>>>      I don't fully understand your objections to the approach taken.
>>>>>> Is there a compatibility issue with the addition of the additional
>>>>>> methods to MulticastSocket?
>>>>>
>>>>> The concern is with setReuseAddress performing an operation that
>>>>> is not clear from the method specification, e.g. from
>>>>> setReuseAddress()
>>>>>
>>>>>      * Enable/disable the SO_REUSEADDR socket option.
>>>>>
>>>>> This is no longer accurate. The proposed changes would affect
>>>>> SO_REUSEPORT too.
>>>>>
>>>>>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
>>>>>> option, this has to be done explicitly via setOption at this level of
>>>>>> abstraction.
>>>>>
>>>>> Yes, it is a bit odd, but these are legacy classes. I am not opposed
>>>>> to adding a new method for this, or something else. I just want to
>>>>> avoid future issues and confusion when setReuseAddress is called and
>>>>> then it is noticed that, the somewhat orthogonal option,
>>>>> SO_REUSEPORT's
>>>>> value has changed. setReuseAddress's spec is very clear about what it
>>>>> does.
>>>>>
>>>>>> MulticastSocket is a subclass of DatagramSocket (that in itself is a
>>>>>> questionable structuring), and as such
>>>>>> has specialized behaviour, and part  of that specialization is the
>>>>>> setting of  the setting SO_REUSEADDR and SO_REUSEPORT
>>>>>> in its constructors, to enable address reuse semantics, prior to
>>>>>> binding
>>>>>> an address.
>>>>>
>>>>> Understood. Of course, the setting of SO_REUSEPORT is new in 9,
>>>>> hence the problem.
>>>>>
>>>>>> As part of that specialization, it would seem appropriate that
>>>>>> MulticastSocket manipulate the SO_REUSEPORT
>>>>>> option in a consistent way. Adding an overridden setReuseAddress(...)
>>>>>> method provides that consistency and
>>>>>> encapsulates the specialized behaviour.
>>>>>
>>>>> I agree with the abstraction, just not that setReuseAddress should
>>>>> be used to achieve it. The name and spec of this method is so
>>>>> tied to SO_REUSEADDR.
>>>>>
>>>>>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT
>>>>>> document clearly how to handle the failing scenario, that an
>>>>>> MulticastSocket
>>>>>> requires both setReuseAddress() and a setOption call to disable
>>>>>> reuseaddress semantics on an unbound MulticastSocket ?
>>>>>
>>>>> That is one option, and the option that I was suggesting as a possible
>>>>> alternative.
>>>>>
>>>>>> This then raises the question of why have a convenience method,
>>>>>> such as
>>>>>> setReuseAddress() in the first place, when it can be handled
>>>>>> adequately via the setOption
>>>>>
>>>>> We are moving away from these option specific getter and setter
>>>>> methods, in favor of the more general get/setOption methods, as
>>>>> the latter are more adaptable.
>>>>>
>>>>> If setReuseAddress is to operate on more than SO_REUSEADDR, then
>>>>> its spec should be very clear about this.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>
>>>>>> regards
>>>>>> Mark
>>>>>>
>>>>>> On 14/09/2016 13:34, Chris Hegarty wrote:
>>>>>>> Mark,
>>>>>>>
>>>>>>> On 14/09/16 13:23, Mark Sheppard wrote:
>>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>     so are you accepting that it is correct to add the overridden
>>>>>>>> methods in MulticastSocket and that these need
>>>>>>>> appropriate javadoc ?
>>>>>>>
>>>>>>> I think we need these, but they should just call their super
>>>>>>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
>>>>>>> exist solely as a place to locate guidance, or a note, that one
>>>>>>> will likely want to set SO_REUSEPORT too.
>>>>>>>
>>>>>>>> or are you advocating pushing the handing of the SO_REUSEPORT into
>>>>>>>> the
>>>>>>>> base DatagramSocket class ?
>>>>>>>
>>>>>>> It is already there. I am not proposing to change this.
>>>>>>>
>>>>>>>> It is not clear how your code changes fit in the proposed fix i.e.
>>>>>>>> the
>>>>>>>> explicit setting of the option to false?
>>>>>>>
>>>>>>> My proposal is an alternative. It is not related to the current
>>>>>>> webrev.
>>>>>>>
>>>>>>>> With the current proposed changes then I think it would be
>>>>>>>> sufficient to
>>>>>>>> invoke setReuseAddress(true) in MulticastSocket constructors
>>>>>>>> rather than
>>>>>>>>
>>>>>>>>         // Enable SO_REUSEADDR before binding
>>>>>>>>         setReuseAddress
>>>>>>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         // Enable SO_REUSEPORT if supported before binding
>>>>>>>>         *if* (supportedOptions
>>>>>>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>))
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> {
>>>>>>>>             *this*.setOption
>>>>>>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *true*);
>>>>>>>>         }
>>>>>>>>
>>>>>>>>
>>>>>>>> as the overridden setReuseAddress takes care of SO_REUSEPORT
>>>>>>>
>>>>>>> Yes, this is what Vyom has proposed, in the webrev.
>>>>>>>
>>>>>>> I would like to explore an alternative, so see what it would look
>>>>>>> like.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>>
>>>>>>>> regards
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On 14/09/2016 11:43, Chris Hegarty wrote:
>>>>>>>>> Vyom,
>>>>>>>>>
>>>>>>>>> On 11/09/16 08:01, Vyom Tewari wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review the below code change.
>>>>>>>>>>
>>>>>>>>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674
>>>>>>>>>>
>>>>>>>>>> Webrev  :
>>>>>>>>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>>>>>>>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This change override the "get/setReuseAddress"  for
>>>>>>>>>> MulticaseSocket
>>>>>>>>>> and
>>>>>>>>>> will abstract with both reuse attributes(SO_REUSEADDR &
>>>>>>>>>> SO_REUSEPORT).
>>>>>>>>>
>>>>>>>>> This issue arises since the changes for 6432031 "Add support for
>>>>>>>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
>>>>>>>>> the available. So setting setReuseAddress(false) alone is no
>>>>>>>>> longer
>>>>>>>>> sufficient to disable address/port reuse, one must also set
>>>>>>>>> SO_REUSEPORT to false.
>>>>>>>>>
>>>>>>>>> I would be really nervous about changing set/getReuseAddress,
>>>>>>>>> without
>>>>>>>>> at least updating the javadoc to indicate that it is now, for MS,
>>>>>>>>> operating on two socket options.  Although, I do have sympathy
>>>>>>>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
>>>>>>>>> dealing with multicasting.
>>>>>>>>>
>>>>>>>>> An alternative, maybe; Since the MS constructors document that
>>>>>>>>> SO_REUSEPORT will be set, where available, maybe a javadoc note
>>>>>>>>> on the set/getReuseAddress methods would be sufficient, that
>>>>>>>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need
>>>>>>>>> to be set to have the desired effect?
>>>>>>>>>
>>>>>>>>> If so, then code would have to:
>>>>>>>>>
>>>>>>>>>     setReuseAddress(false);
>>>>>>>>>
>>>>>>>>>     if
>>>>>>>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>>>>>>>> this.setOption(StandardSocketOptions.SO_REUSEPORT, false);
>>>>>>>>>
>>>>>>>>>   , but at least it is explicit.
>>>>>>>>>
>>>>>>>>> Q: not all MS constructors document that SO_REUSEPORT is set, but
>>>>>>>>> they should, right? This seems to have slipped past during 6432031
>>>>>>>>> [1].
>>>>>>>>>
>>>>>>>>> -Chris.
>>>>>>>>>
>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>>>>>>
>>>>>>
>>>
>

From christoph.langer at sap.com  Wed Sep 28 13:54:06 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 28 Sep 2016 13:54:06 +0000
Subject: RFR(XS): 8166584: Remove obsolete utility function
	NET_ThrowSocketException in windows libnet
In-Reply-To: <683D7081-31B5-4C76-A339-614072712D49@oracle.com>
References: <5712036a80ef4a8a8a76a4a9512d3a58@DEWDFE13DE11.global.corp.sap>
	<3d9a7d3b-58b3-68e5-a8b1-27cb835b603e@oracle.com>
	<0e33d243428e422da2a9c80172d411d1@DEWDFE13DE11.global.corp.sap>
	<6707B730-8A1B-4616-8E25-129079D67156@oracle.com>
	<a3cd2afa8d43420b9e350c33de875526@DEWDFE13DE11.global.corp.sap>
	<683D7081-31B5-4C76-A339-614072712D49@oracle.com>
Message-ID: <26083a9023ec442db6c7384f6b9816b4@DEWDFE13DE11.global.corp.sap>

Thanks, I pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2b5229c75e93

Best regards
Christoph

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Dienstag, 27. September 2016 21:24
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> NET_ThrowSocketException in windows libnet
> 
> 
> > On 27 Sep 2016, at 19:56, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> >
> > Chris,
> >
> > thanks for your input.
> >
> > If there's no objections I'd push it like this later tomorrow:
> > http://cr.openjdk.java.net/~clanger/webrevs/8166584.2/
> 
> Looks ok to me Christoph.
> 
> Thanks,
> -Chris.
> 
> > I've replaced the JNU_JAVANETPKG and JNU_JAVAIOPKG macros with the full
> exception class names.
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >> Sent: Dienstag, 27. September 2016 10:10
> >> To: Langer, Christoph <christoph.langer at sap.com>
> >> Cc: net-dev at openjdk.java.net
> >> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> >> NET_ThrowSocketException in windows libnet
> >>
> >> Christoph,
> >>
> >> On 26 Sep 2016, at 18:58, Langer, Christoph <christoph.langer at sap.com>
> >> wrote:
> >>>
> >>> Hi Chris,
> >>>
> >>> I agree with your comment on the NPE. It would probably be wrong. So I
> >> restored the old code and also removed the comments suggesting the NPE.
> >> Here is my new webrev:
> >> http://cr.openjdk.java.net/~clanger/webrevs/8166584.1/
> >>
> >> This looks fine.
> >>
> >>> What I was thinking a bit more about after I posted my initial webrev was
> the
> >> fact that the old NET_ThrowSocketException would register a GlobalRef to
> >> java/net/SocketException whereas the other, more generic code would
> always
> >> use the lookup by name. Would you think it is a performance benefit to keep
> a
> >> reference to a standard exception class in some place and use it for
> throwing
> >> or is it better to always look up the class? Throwing those kind of exceptions
> is
> >> probably not on the hot path anyway - but on the other hand it should be no
> >> issue to keep references to these very basic class types. What's your view on
> >> that?
> >>
> >> I don?t believe that using a GlobalRef is worth it here. It adds a little
> >> complication, while not offering much benefit. JNU_ThrowByName
> >> should be fine.
> >>
> >>> And another probably aesthetic thing: I notice that sometimes a
> >> JNU_JAVANETPKG "SocketException" is used and sometimes a
> >> "java/net/SocketException", even within the same file like
> SocketInputStream.c.
> >> Maybe I should unify this in the files that I touch here and if yes, shall I use
> the
> >> literal name or the JNU_JAVANETPKG define? Any opinion on that?
> >>
> >> My preference is to remove JNU_JAVANETPKG, and just use "java/net/?.
> >>
> >> -Chris
> >>
> >>> Thanks for taking care of this,
> >>> Christoph
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >>>> Sent: Montag, 26. September 2016 16:51
> >>>> To: Langer, Christoph <christoph.langer at sap.com>; net-
> >> dev at openjdk.java.net
> >>>> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> >>>> NET_ThrowSocketException in windows libnet
> >>>>
> >>>> Christoph,
> >>>>
> >>>> On 22/09/16 21:59, Langer, Christoph wrote:
> >>>>> Hi,
> >>>>>
> >>>>> while looking at utility functions for creating exceptions in
> >>>>> libjava/libnet I found a small spot that should be consolidated right
> away.
> >>>>>
> >>>>>
> >>>>> The function NET_ThrowSocketException does only exist in the windows
> >>>>> native implementation and is only used in 3 places in
> >>>>> SocketInputStream.c. I removed this in favor of directly calling
> >>>>> JNU_ThrowByName as the Unix variant of that code already does.
> >>>>>
> >>>>>
> >>>>> In that function Java_java_net_SocketInputStream_socketRead0 I also
> >>>>> replaced throwing a SocketException with throwing an NPE in the rare
> >>>>> case that a the JNI input for the file descriptor is null. That's
> >>>>> probably more natural and should virtually never occur anyways.
> >>>>
> >>>> Hmmm... I'm not sure about this. SocketException is thrown on
> >>>> unix too for a similar situation. More significantly, a null value
> >>>> represents that the socket has been, possibly asynchronously,
> >>>> closed.
> >>>>
> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166584
> >>>>>
> >>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166584.0/
> >>>>
> >>>> Other than the above concern, the remainder of the code looks ok
> >>>> to me.
> >>>>
> >>>> -Chris.
> >


From christoph.langer at sap.com  Wed Sep 28 15:39:46 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 28 Sep 2016 15:39:46 +0000
Subject: RFR(S): 8166850: No runtime error expected after calling
	NET_MapSocketOption
Message-ID: <4ea21b3c8a1f47418058004c31e46d72@DEWDFE13DE11.global.corp.sap>

Hi,

during my work on exception sites in the JDK, I spotted another minor place that should be fixed. In the Windows native implementations of DualStackPlainDatagramSocketImpl and DualStackPlainSocketImpl, there are calls to evaluate OS API errors after unsuccessful return of NET_MapSocketOption where this should not be done. Please review my fix. I also took the opportunity to clean up some indentations.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166850
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166850.0/

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160928/54fc3480/attachment.html>

From yingqi.lu at intel.com  Wed Sep 28 19:02:05 2016
From: yingqi.lu at intel.com (Lu, Yingqi)
Date: Wed, 28 Sep 2016 19:02:05 +0000
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
	<2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
	<850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5137216@ORSMSX113.amr.corp.intel.com>

Hi Vyom,

Thank you very much checking with us.

We agree that SO_RESUEADDR and SO_REUSEPORT behave the same way for MulticastSocket. There is no need to check and enable SO_REUSEPORT for this particular type of socket. SO_REUSEADDR is sufficient.

Thanks,
Lucy

From: Vyom Tewari [mailto:vyom.tewari at oracle.com]
Sent: Wednesday, September 28, 2016 1:26 AM
To: Chris Hegarty <chris.hegarty at oracle.com>; Mark Sheppard <mark.sheppard at oracle.com>; net-dev <net-dev at openjdk.java.net>; Kaczmarek, Eric <eric.kaczmarek at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kharbas, Kishor <kishor.kharbas at intel.com>; Aundhe, Shirish <shirish.aundhe at intel.com>; Lu, Yingqi <yingqi.lu at intel.com>
Subject: Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)


Hi All,

I had off line discussion here at Oracle and we decided  not to override getReuseAddr/setReuseAddr for MulticastSocket. If user wants, he can set the SO_REUSEPORT with "setOption" before bind.

For MulticastSocket SO_REUSEADDR&SO_REUSEPORT are semantically equivalent which means either option will be sufficient to indicate that the address&port is reusable. So setting SO_REUSEPORT in constructor is really necessary/required ?

I am looking some comments on this from Intel people(they are in mail chain) who did this original change, before we decide how we wants to proceed on this issue.

Thanks,

Vyom

On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote:
On 14/09/16 15:53, Mark Sheppard wrote:


that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the
same could have been argued for the original
invocation of setReuseAddress, by default , in the constructors, which
is encapsulating, what pereceived as, common or defacto
practice wrt applying SO_REUSEADDR on mcast sockets at the system level.
As I understand it, it is generally perceived that SO_REUSEADDR and
SO_REUSEPORT are semantically equivalent for multicast sockets.
As such, I think in the case of MulticastSocket, the fact that the
setRuseAddress() is called in the constructor, it is appropriate
to set SO_REUSEPORT also when it exists in the OS.

I take your point on the semantics of setReuseAddress in DatagramSocket
as per its spec. The spec does allude to MulticastSocket.
As such, the current proposal's changes just lack the appropriate
javadoc to describe its behavior, and its additional functionality of
setting SO_REUSEPORT.
It is not necessary that overridden method should mirror the semantics
of the base class method.
If it is accepted that it is generally perceived that SO_REUSEADDR and
SO_REUSEPORT are semantically equivalent for multicast sockets,
then it seems appropriate that an overriding setReuseAddress(..) method
in MulticastSocket can reflect this.

That sounds reasonable.

-Chris.


regards
Mark



On 14/09/2016 14:58, Chris Hegarty wrote:

One additional remark.

Was it appropriate to update the legacy MC constructors
to set the new JDK 9 SO_REUSEPORT in the first place?
This can be achievable, opt-in from new code, by creating
an unbound MS, setting the option, then binding.

-Chris.

On 14/09/16 14:47, Chris Hegarty wrote:

Mark,

On 14/09/16 14:22, Mark Sheppard wrote:


Hi Chris,
     I don't fully understand your objections to the approach taken.
Is there a compatibility issue with the addition of the additional
methods to MulticastSocket?

The concern is with setReuseAddress performing an operation that
is not clear from the method specification, e.g. from setReuseAddress()

     * Enable/disable the SO_REUSEADDR socket option.

This is no longer accurate. The proposed changes would affect
SO_REUSEPORT too.


I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT
option, this has to be done explicitly via setOption at this level of
abstraction.

Yes, it is a bit odd, but these are legacy classes. I am not opposed
to adding a new method for this, or something else. I just want to
avoid future issues and confusion when setReuseAddress is called and
then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's
value has changed. setReuseAddress's spec is very clear about what it
does.


MulticastSocket is a subclass of DatagramSocket (that in itself is a
questionable structuring), and as such
has specialized behaviour, and part  of that specialization is the
setting of  the setting SO_REUSEADDR and SO_REUSEPORT
in its constructors, to enable address reuse semantics, prior to
binding
an address.

Understood. Of course, the setting of SO_REUSEPORT is new in 9,
hence the problem.


As part of that specialization, it would seem appropriate that
MulticastSocket manipulate the SO_REUSEPORT
option in a consistent way. Adding an overridden setReuseAddress(...)
method provides that consistency and
encapsulates the specialized behaviour.

I agree with the abstraction, just not that setReuseAddress should
be used to achieve it. The name and spec of this method is so
tied to SO_REUSEADDR.


Is alternatively proposal to NOT do anything to MulticastSocket, BUT
document clearly how to handle the failing scenario, that an
MulticastSocket
requires both setReuseAddress() and a setOption call to disable
reuseaddress semantics on an unbound MulticastSocket ?

That is one option, and the option that I was suggesting as a possible
alternative.


This then raises the question of why have a convenience method, such as
setReuseAddress() in the first place, when it can be handled
adequately via the setOption

We are moving away from these option specific getter and setter
methods, in favor of the more general get/setOption methods, as
the latter are more adaptable.

If setReuseAddress is to operate on more than SO_REUSEADDR, then
its spec should be very clear about this.

-Chris.



regards
Mark

On 14/09/2016 13:34, Chris Hegarty wrote:

Mark,

On 14/09/16 13:23, Mark Sheppard wrote:


Hi Chris,
    so are you accepting that it is correct to add the overridden
methods in MulticastSocket and that these need
appropriate javadoc ?

I think we need these, but they should just call their super
equivalents, i.e. no implicit setting of SO_REUSEPORT. They would
exist solely as a place to locate guidance, or a note, that one
will likely want to set SO_REUSEPORT too.


or are you advocating pushing the handing of the SO_REUSEPORT into
the
base DatagramSocket class ?

It is already there. I am not proposing to change this.


It is not clear how your code changes fit in the proposed fix i.e.
the
explicit setting of the option to false?

My proposal is an alternative. It is not related to the current
webrev.


With the current proposed changes then I think it would be
sufficient to
invoke setReuseAddress(true) in MulticastSocket constructors
rather than

        // Enable SO_REUSEADDR before binding
        setReuseAddress
<https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);




        // Enable SO_REUSEPORT if supported before binding
        *if* (supportedOptions
<https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions><https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains



<https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions



<https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT



<https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>))


{
            *this*.setOption
<https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions



<https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT



<https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev><https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,


*true*);
        }


as the overridden setReuseAddress takes care of SO_REUSEPORT

Yes, this is what Vyom has proposed, in the webrev.

I would like to explore an alternative, so see what it would look
like.

-Chris.



regards
Mark

On 14/09/2016 11:43, Chris Hegarty wrote:

Vyom,

On 11/09/16 08:01, Vyom Tewari wrote:

Hi All,

Please review the below code change.

Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674

Webrev  :
http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html<http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
<http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html><http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>


This change override the "get/setReuseAddress"  for MulticaseSocket
and
will abstract with both reuse attributes(SO_REUSEADDR &
SO_REUSEPORT).

This issue arises since the changes for 6432031 "Add support for
SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if
the available. So setting setReuseAddress(false) alone is no longer
sufficient to disable address/port reuse, one must also set
SO_REUSEPORT to false.

I would be really nervous about changing set/getReuseAddress,
without
at least updating the javadoc to indicate that it is now, for MS,
operating on two socket options.  Although, I do have sympathy
here since SO_REUSEPORT and SO_REUSEADDR are almost identical when
dealing with multicasting.

An alternative, maybe; Since the MS constructors document that
SO_REUSEPORT will be set, where available, maybe a javadoc note
on the set/getReuseAddress methods would be sufficient, that
indicates that StandardSocketOptions#SO_REUSEPORT may also need
to be set to have the desired effect?

If so, then code would have to:

    setReuseAddress(false);

    if
(supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
this.setOption(StandardSocketOptions.SO_REUSEPORT, false);

  , but at least it is explicit.

Q: not all MS constructors document that SO_REUSEPORT is set, but
they should, right? This seems to have slipped past during 6432031
[1].

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-6432031




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160928/50522a3a/attachment-0001.html>

From chris.hegarty at oracle.com  Wed Sep 28 20:08:21 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 28 Sep 2016 21:08:21 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5137216@ORSMSX113.amr.corp.intel.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
	<2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
	<850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
	<9ACD5B67AAC5594CB6268234CF29CF9AA5137216@ORSMSX113.amr.corp.intel.com>
Message-ID: <2AFB39BF-AB16-4DFA-BAF8-02FE1E84C0FA@oracle.com>

Thank you Lucy,

We?ll proceed with removing the setting of SO_REUSEPORT from the
MulticastSocket constructor and spec.

-Chris.

> On 28 Sep 2016, at 20:02, Lu, Yingqi <yingqi.lu at intel.com> wrote:
> 
> Hi Vyom,
>  
> Thank you very much checking with us.
>  
> We agree that SO_RESUEADDR and SO_REUSEPORT behave the same way for MulticastSocket. There is no need to check and enable SO_REUSEPORT for this particular type of socket. SO_REUSEADDR is sufficient.
>  
> Thanks,
> Lucy
>  
>  <>From: Vyom Tewari [mailto:vyom.tewari at oracle.com] 
> Sent: Wednesday, September 28, 2016 1:26 AM
> To: Chris Hegarty <chris.hegarty at oracle.com>; Mark Sheppard <mark.sheppard at oracle.com>; net-dev <net-dev at openjdk.java.net>; Kaczmarek, Eric <eric.kaczmarek at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kharbas, Kishor <kishor.kharbas at intel.com>; Aundhe, Shirish <shirish.aundhe at intel.com>; Lu, Yingqi <yingqi.lu at intel.com>
> Subject: Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)
>  
> Hi All,
> 
> I had off line discussion here at Oracle and we decided  not to override getReuseAddr/setReuseAddr for MulticastSocket. If user wants, he can set the SO_REUSEPORT with "setOption" before bind.
> 
> For MulticastSocket SO_REUSEADDR&SO_REUSEPORT are semantically equivalent which means either option will be sufficient to indicate that the address&port is reusable. So setting SO_REUSEPORT in constructor is really necessary/required ?
> 
> I am looking some comments on this from Intel people(they are in mail chain) who did this original change, before we decide how we wants to proceed on this issue.
> 
> Thanks,
> 
> Vyom
> 
>  
> On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote:
> On 14/09/16 15:53, Mark Sheppard wrote: 
> 
> 
> that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the 
> same could have been argued for the original 
> invocation of setReuseAddress, by default , in the constructors, which 
> is encapsulating, what pereceived as, common or defacto 
> practice wrt applying SO_REUSEADDR on mcast sockets at the system level. 
> As I understand it, it is generally perceived that SO_REUSEADDR and 
> SO_REUSEPORT are semantically equivalent for multicast sockets. 
> As such, I think in the case of MulticastSocket, the fact that the 
> setRuseAddress() is called in the constructor, it is appropriate 
> to set SO_REUSEPORT also when it exists in the OS. 
> 
> I take your point on the semantics of setReuseAddress in DatagramSocket 
> as per its spec. The spec does allude to MulticastSocket. 
> As such, the current proposal's changes just lack the appropriate 
> javadoc to describe its behavior, and its additional functionality of 
> setting SO_REUSEPORT. 
> It is not necessary that overridden method should mirror the semantics 
> of the base class method. 
> If it is accepted that it is generally perceived that SO_REUSEADDR and 
> SO_REUSEPORT are semantically equivalent for multicast sockets, 
> then it seems appropriate that an overriding setReuseAddress(..) method 
> in MulticastSocket can reflect this. 
> 
> That sounds reasonable. 
> 
> -Chris. 
> 
> 
> regards 
> Mark 
> 
> 
> 
> On 14/09/2016 14:58, Chris Hegarty wrote: 
> 
> One additional remark. 
> 
> Was it appropriate to update the legacy MC constructors 
> to set the new JDK 9 SO_REUSEPORT in the first place? 
> This can be achievable, opt-in from new code, by creating 
> an unbound MS, setting the option, then binding. 
> 
> -Chris. 
> 
> On 14/09/16 14:47, Chris Hegarty wrote: 
> 
> Mark, 
> 
> On 14/09/16 14:22, Mark Sheppard wrote: 
> 
> 
> Hi Chris, 
>      I don't fully understand your objections to the approach taken. 
> Is there a compatibility issue with the addition of the additional 
> methods to MulticastSocket? 
> 
> The concern is with setReuseAddress performing an operation that 
> is not clear from the method specification, e.g. from setReuseAddress() 
> 
>      * Enable/disable the SO_REUSEADDR socket option. 
> 
> This is no longer accurate. The proposed changes would affect 
> SO_REUSEPORT too. 
> 
> 
> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT 
> option, this has to be done explicitly via setOption at this level of 
> abstraction. 
> 
> Yes, it is a bit odd, but these are legacy classes. I am not opposed 
> to adding a new method for this, or something else. I just want to 
> avoid future issues and confusion when setReuseAddress is called and 
> then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's 
> value has changed. setReuseAddress's spec is very clear about what it 
> does. 
> 
> 
> MulticastSocket is a subclass of DatagramSocket (that in itself is a 
> questionable structuring), and as such 
> has specialized behaviour, and part  of that specialization is the 
> setting of  the setting SO_REUSEADDR and SO_REUSEPORT 
> in its constructors, to enable address reuse semantics, prior to 
> binding 
> an address. 
> 
> Understood. Of course, the setting of SO_REUSEPORT is new in 9, 
> hence the problem. 
> 
> 
> As part of that specialization, it would seem appropriate that 
> MulticastSocket manipulate the SO_REUSEPORT 
> option in a consistent way. Adding an overridden setReuseAddress(...) 
> method provides that consistency and 
> encapsulates the specialized behaviour. 
> 
> I agree with the abstraction, just not that setReuseAddress should 
> be used to achieve it. The name and spec of this method is so 
> tied to SO_REUSEADDR. 
> 
> 
> Is alternatively proposal to NOT do anything to MulticastSocket, BUT 
> document clearly how to handle the failing scenario, that an 
> MulticastSocket 
> requires both setReuseAddress() and a setOption call to disable 
> reuseaddress semantics on an unbound MulticastSocket ? 
> 
> That is one option, and the option that I was suggesting as a possible 
> alternative. 
> 
> 
> This then raises the question of why have a convenience method, such as 
> setReuseAddress() in the first place, when it can be handled 
> adequately via the setOption 
> 
> We are moving away from these option specific getter and setter 
> methods, in favor of the more general get/setOption methods, as 
> the latter are more adaptable. 
> 
> If setReuseAddress is to operate on more than SO_REUSEADDR, then 
> its spec should be very clear about this. 
> 
> -Chris. 
> 
> 
> 
> regards 
> Mark 
> 
> On 14/09/2016 13:34, Chris Hegarty wrote: 
> 
> Mark, 
> 
> On 14/09/16 13:23, Mark Sheppard wrote: 
> 
> 
> Hi Chris, 
>     so are you accepting that it is correct to add the overridden 
> methods in MulticastSocket and that these need 
> appropriate javadoc ? 
> 
> I think we need these, but they should just call their super 
> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would 
> exist solely as a place to locate guidance, or a note, that one 
> will likely want to set SO_REUSEPORT too. 
> 
> 
> or are you advocating pushing the handing of the SO_REUSEPORT into 
> the 
> base DatagramSocket class ? 
> 
> It is already there. I am not proposing to change this. 
> 
> 
> It is not clear how your code changes fit in the proposed fix i.e. 
> the 
> explicit setting of the option to false? 
> 
> My proposal is an alternative. It is not related to the current 
> webrev. 
> 
> 
> With the current proposed changes then I think it would be 
> sufficient to 
> invoke setReuseAddress(true) in MulticastSocket constructors 
> rather than 
> 
>         // Enable SO_REUSEADDR before binding 
>         setReuseAddress 
> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*); 
> 
> 
> 
> 
>         // Enable SO_REUSEPORT if supported before binding 
>         *if* (supportedOptions 
> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains 
> 
> 
> 
> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions 
> 
> 
> 
> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
> 
> 
> 
> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) 
> 
> 
> { 
>             *this*.setOption 
> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions 
> 
> 
> 
> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
> 
> 
> 
> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>, 
> 
> 
> *true*); 
>         } 
> 
> 
> as the overridden setReuseAddress takes care of SO_REUSEPORT 
> 
> Yes, this is what Vyom has proposed, in the webrev. 
> 
> I would like to explore an alternative, so see what it would look 
> like. 
> 
> -Chris. 
> 
> 
> 
> regards 
> Mark 
> 
> On 14/09/2016 11:43, Chris Hegarty wrote: 
> 
> Vyom, 
> 
> On 11/09/16 08:01, Vyom Tewari wrote: 
> 
> Hi All, 
> 
> Please review the below code change. 
> 
> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674 <https://bugs.openjdk.java.net/browse/JDK-8153674> 
> 
> Webrev  : 
> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html> 
> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
> 
> 
> This change override the "get/setReuseAddress"  for MulticaseSocket 
> and 
> will abstract with both reuse attributes(SO_REUSEADDR & 
> SO_REUSEPORT). 
> 
> This issue arises since the changes for 6432031 "Add support for 
> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if 
> the available. So setting setReuseAddress(false) alone is no longer 
> sufficient to disable address/port reuse, one must also set 
> SO_REUSEPORT to false. 
> 
> I would be really nervous about changing set/getReuseAddress, 
> without 
> at least updating the javadoc to indicate that it is now, for MS, 
> operating on two socket options.  Although, I do have sympathy 
> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when 
> dealing with multicasting. 
> 
> An alternative, maybe; Since the MS constructors document that 
> SO_REUSEPORT will be set, where available, maybe a javadoc note 
> on the set/getReuseAddress methods would be sufficient, that 
> indicates that StandardSocketOptions#SO_REUSEPORT may also need 
> to be set to have the desired effect? 
> 
> If so, then code would have to: 
> 
>     setReuseAddress(false); 
> 
>     if 
> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT)) 
> this.setOption(StandardSocketOptions.SO_REUSEPORT, false); 
> 
>   , but at least it is explicit. 
> 
> Q: not all MS constructors document that SO_REUSEPORT is set, but 
> they should, right? This seems to have slipped past during 6432031 
> [1]. 
> 
> -Chris. 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-6432031 <https://bugs.openjdk.java.net/browse/JDK-6432031>
>  
>  
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160928/4f74ebf2/attachment-0001.html>

From vyom.tewari at oracle.com  Thu Sep 29 08:16:22 2016
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 29 Sep 2016 13:46:22 +0530
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <2AFB39BF-AB16-4DFA-BAF8-02FE1E84C0FA@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
	<2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
	<850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
	<9ACD5B67AAC5594CB6268234CF29CF9AA5137216@ORSMSX113.amr.corp.intel.com>
	<2AFB39BF-AB16-4DFA-BAF8-02FE1E84C0FA@oracle.com>
Message-ID: <b704d8d3-9d44-138a-5c4a-dfa57f9bea53@oracle.com>

Hi All,

Please find the latest 
webrev(http://cr.openjdk.java.net/~vtewari/8153674/webrev0.1/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.1/index.html>). I 
had removed the SO_REUSEPORT & spec from constructor.

Thanks,

Vyom


On Thursday 29 September 2016 01:38 AM, Chris Hegarty wrote:
> Thank you Lucy,
>
> We?ll proceed with removing the setting of SO_REUSEPORT from the
> MulticastSocket constructor and spec.
>
> -Chris.
>
>> On 28 Sep 2016, at 20:02, Lu, Yingqi <yingqi.lu at intel.com 
>> <mailto:yingqi.lu at intel.com>> wrote:
>>
>> Hi Vyom,
>> Thank you very much checking with us.
>> We agree that SO_RESUEADDR and SO_REUSEPORT behave the same way for 
>> MulticastSocket. There is no need to check and enable SO_REUSEPORT 
>> for this particular type of socket. SO_REUSEADDR is sufficient.
>> Thanks,
>> Lucy
>> *From:*Vyom Tewari [mailto:vyom.tewari at oracle.com]
>> *Sent:*Wednesday, September 28, 2016 1:26 AM
>> *To:*Chris Hegarty <chris.hegarty at oracle.com 
>> <mailto:chris.hegarty at oracle.com>>; Mark Sheppard 
>> <mark.sheppard at oracle.com <mailto:mark.sheppard at oracle.com>>; net-dev 
>> <net-dev at openjdk.java.net <mailto:net-dev at openjdk.java.net>>; 
>> Kaczmarek, Eric <eric.kaczmarek at intel.com 
>> <mailto:eric.kaczmarek at intel.com>>; Viswanathan, Sandhya 
>> <sandhya.viswanathan at intel.com 
>> <mailto:sandhya.viswanathan at intel.com>>; Kharbas, Kishor 
>> <kishor.kharbas at intel.com <mailto:kishor.kharbas at intel.com>>; Aundhe, 
>> Shirish <shirish.aundhe at intel.com <mailto:shirish.aundhe at intel.com>>; 
>> Lu, Yingqi <yingqi.lu at intel.com <mailto:yingqi.lu at intel.com>>
>> *Subject:*Re: RFR 8153674: Expected SocketException not thrown when 
>> calling bind() with setReuseAddress(false)
>>
>> Hi All,
>>
>> I had off line discussion here at Oracle and we decided  not to 
>> override getReuseAddr/setReuseAddr for MulticastSocket. If user 
>> wants, he can set the SO_REUSEPORT with "setOption"before bind.
>>
>> For MulticastSocketSO_REUSEADDR&SO_REUSEPORT are semantically 
>> equivalent which means either option will be sufficient to indicate 
>> that the address&port is reusable. So setting SO_REUSEPORT in 
>> constructor is really necessary/required ?
>>
>> I am looking some comments on this from Intel people(they are in mail 
>> chain) who did this original change, before we decide how we wants to 
>> proceed on this issue.
>>
>> Thanks,
>>
>> Vyom
>>
>> On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote:
>>
>>     On 14/09/16 15:53, Mark Sheppard wrote:
>>
>>
>>         that's true wrt SO_REUSEPORT in MulticastSocket constructor.
>>         But the
>>         same could have been argued for the original
>>         invocation of setReuseAddress, by default , in the
>>         constructors, which
>>         is encapsulating, what pereceived as, common or defacto
>>         practice wrt applying SO_REUSEADDR on mcast sockets at the
>>         system level.
>>         As I understand it, it is generally perceived that
>>         SO_REUSEADDR and
>>         SO_REUSEPORT are semantically equivalent for multicast sockets.
>>         As such, I think in the case of MulticastSocket, the fact
>>         that the
>>         setRuseAddress() is called in the constructor, it is appropriate
>>         to set SO_REUSEPORT also when it exists in the OS.
>>
>>         I take your point on the semantics of setReuseAddress in
>>         DatagramSocket
>>         as per its spec. The spec does allude to MulticastSocket.
>>         As such, the current proposal's changes just lack the appropriate
>>         javadoc to describe its behavior, and its additional
>>         functionality of
>>         setting SO_REUSEPORT.
>>         It is not necessary that overridden method should mirror the
>>         semantics
>>         of the base class method.
>>         If it is accepted that it is generally perceived that
>>         SO_REUSEADDR and
>>         SO_REUSEPORT are semantically equivalent for multicast sockets,
>>         then it seems appropriate that an overriding
>>         setReuseAddress(..) method
>>         in MulticastSocket can reflect this.
>>
>>
>>     That sounds reasonable.
>>
>>     -Chris.
>>
>>
>>         regards
>>         Mark
>>
>>
>>
>>         On 14/09/2016 14:58, Chris Hegarty wrote:
>>
>>             One additional remark.
>>
>>             Was it appropriate to update the legacy MC constructors
>>             to set the new JDK 9 SO_REUSEPORT in the first place?
>>             This can be achievable, opt-in from new code, by creating
>>             an unbound MS, setting the option, then binding.
>>
>>             -Chris.
>>
>>             On 14/09/16 14:47, Chris Hegarty wrote:
>>
>>                 Mark,
>>
>>                 On 14/09/16 14:22, Mark Sheppard wrote:
>>
>>
>>                     Hi Chris,
>>                          I don't fully understand your objections to
>>                     the approach taken.
>>                     Is there a compatibility issue with the addition
>>                     of the additional
>>                     methods to MulticastSocket?
>>
>>
>>                 The concern is with setReuseAddress performing an
>>                 operation that
>>                 is not clear from the method specification, e.g. from
>>                 setReuseAddress()
>>
>>                      * Enable/disable the SO_REUSEADDR socket option.
>>
>>                 This is no longer accurate. The proposed changes
>>                 would affect
>>                 SO_REUSEPORT too.
>>
>>
>>                     I don't see Datagram.setReuseAddress(...)
>>                     handling the SO_REUSEPORT
>>                     option, this has to be done explicitly via
>>                     setOption at this level of
>>                     abstraction.
>>
>>
>>                 Yes, it is a bit odd, but these are legacy classes. I
>>                 am not opposed
>>                 to adding a new method for this, or something else. I
>>                 just want to
>>                 avoid future issues and confusion when
>>                 setReuseAddress is called and
>>                 then it is noticed that, the somewhat orthogonal
>>                 option, SO_REUSEPORT's
>>                 value has changed. setReuseAddress's spec is very
>>                 clear about what it
>>                 does.
>>
>>
>>                     MulticastSocket is a subclass of DatagramSocket
>>                     (that in itself is a
>>                     questionable structuring), and as such
>>                     has specialized behaviour, and part  of that
>>                     specialization is the
>>                     setting of  the setting SO_REUSEADDR and SO_REUSEPORT
>>                     in its constructors, to enable address reuse
>>                     semantics, prior to
>>                     binding
>>                     an address.
>>
>>
>>                 Understood. Of course, the setting of SO_REUSEPORT is
>>                 new in 9,
>>                 hence the problem.
>>
>>
>>                     As part of that specialization, it would seem
>>                     appropriate that
>>                     MulticastSocket manipulate the SO_REUSEPORT
>>                     option in a consistent way. Adding an overridden
>>                     setReuseAddress(...)
>>                     method provides that consistency and
>>                     encapsulates the specialized behaviour.
>>
>>
>>                 I agree with the abstraction, just not that
>>                 setReuseAddress should
>>                 be used to achieve it. The name and spec of this
>>                 method is so
>>                 tied to SO_REUSEADDR.
>>
>>
>>                     Is alternatively proposal to NOT do anything to
>>                     MulticastSocket, BUT
>>                     document clearly how to handle the failing
>>                     scenario, that an
>>                     MulticastSocket
>>                     requires both setReuseAddress() and a setOption
>>                     call to disable
>>                     reuseaddress semantics on an unbound
>>                     MulticastSocket ?
>>
>>
>>                 That is one option, and the option that I was
>>                 suggesting as a possible
>>                 alternative.
>>
>>
>>                     This then raises the question of why have a
>>                     convenience method, such as
>>                     setReuseAddress() in the first place, when it can
>>                     be handled
>>                     adequately via the setOption
>>
>>
>>                 We are moving away from these option specific getter
>>                 and setter
>>                 methods, in favor of the more general get/setOption
>>                 methods, as
>>                 the latter are more adaptable.
>>
>>                 If setReuseAddress is to operate on more than
>>                 SO_REUSEADDR, then
>>                 its spec should be very clear about this.
>>
>>                 -Chris.
>>
>>
>>
>>                     regards
>>                     Mark
>>
>>                     On 14/09/2016 13:34, Chris Hegarty wrote:
>>
>>                         Mark,
>>
>>                         On 14/09/16 13:23, Mark Sheppard wrote:
>>
>>
>>                             Hi Chris,
>>                                 so are you accepting that it is
>>                             correct to add the overridden
>>                             methods in MulticastSocket and that these
>>                             need
>>                             appropriate javadoc ?
>>
>>
>>                         I think we need these, but they should just
>>                         call their super
>>                         equivalents, i.e. no implicit setting of
>>                         SO_REUSEPORT. They would
>>                         exist solely as a place to locate guidance,
>>                         or a note, that one
>>                         will likely want to set SO_REUSEPORT too.
>>
>>
>>                             or are you advocating pushing the handing
>>                             of the SO_REUSEPORT into
>>                             the
>>                             base DatagramSocket class ?
>>
>>
>>                         It is already there. I am not proposing to
>>                         change this.
>>
>>
>>                             It is not clear how your code changes fit
>>                             in the proposed fix i.e.
>>                             the
>>                             explicit setting of the option to false?
>>
>>
>>                         My proposal is an alternative. It is not
>>                         related to the current
>>                         webrev.
>>
>>
>>                             With the current proposed changes then I
>>                             think it would be
>>                             sufficient to
>>                             invoke setReuseAddress(true) in
>>                             MulticastSocket constructors
>>                             rather than
>>
>>                                     // Enable SO_REUSEADDR before binding
>>                                     setReuseAddress
>>                             <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*);
>>
>>
>>
>>
>>                                     // Enable SO_REUSEPORT if
>>                             supported before binding
>>                                     *if* (supportedOptions
>>                             <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>
>>                             <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains
>>
>>
>>
>>                             <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions
>>
>>
>>
>>                             <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>
>>
>>
>>                             <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>))
>>
>>
>>                             {
>>                                         *this*.setOption
>>                             <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions
>>
>>
>>
>>                             <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT
>>
>>
>>
>>                             <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>
>>                             <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>,
>>
>>
>>                             *true*);
>>                                     }
>>
>>
>>                             as the overridden setReuseAddress takes
>>                             care of SO_REUSEPORT
>>
>>
>>                         Yes, this is what Vyom has proposed, in the
>>                         webrev.
>>
>>                         I would like to explore an alternative, so
>>                         see what it would look
>>                         like.
>>
>>                         -Chris.
>>
>>
>>
>>                             regards
>>                             Mark
>>
>>                             On 14/09/2016 11:43, Chris Hegarty wrote:
>>
>>                                 Vyom,
>>
>>                                 On 11/09/16 08:01, Vyom Tewari wrote:
>>
>>                                     Hi All,
>>
>>                                     Please review the below code change.
>>
>>                                     Bug       
>>                                     :https://bugs.openjdk.java.net/browse/JDK-8153674
>>
>>                                     Webrev  :
>>                                     http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html
>>                                     <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>                                     <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>                                     <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>
>>
>>                                     This change override the
>>                                     "get/setReuseAddress"  for
>>                                     MulticaseSocket
>>                                     and
>>                                     will abstract with both reuse
>>                                     attributes(SO_REUSEADDR &
>>                                     SO_REUSEPORT).
>>
>>
>>                                 This issue arises since the changes
>>                                 for 6432031 "Add support for
>>                                 SO_REUSEPORT" [1], which sets
>>                                 SO_REUSEPORT on MulticastSocket, if
>>                                 the available. So setting
>>                                 setReuseAddress(false) alone is no longer
>>                                 sufficient to disable address/port
>>                                 reuse, one must also set
>>                                 SO_REUSEPORT to false.
>>
>>                                 I would be really nervous about
>>                                 changing set/getReuseAddress,
>>                                 without
>>                                 at least updating the javadoc to
>>                                 indicate that it is now, for MS,
>>                                 operating on two socket options.
>>                                 Although, I do have sympathy
>>                                 here since SO_REUSEPORT and
>>                                 SO_REUSEADDR are almost identical when
>>                                 dealing with multicasting.
>>
>>                                 An alternative, maybe; Since the MS
>>                                 constructors document that
>>                                 SO_REUSEPORT will be set, where
>>                                 available, maybe a javadoc note
>>                                 on the set/getReuseAddress methods
>>                                 would be sufficient, that
>>                                 indicates that
>>                                 StandardSocketOptions#SO_REUSEPORT
>>                                 may also need
>>                                 to be set to have the desired effect?
>>
>>                                 If so, then code would have to:
>>
>>                                     setReuseAddress(false);
>>
>>                                     if
>>                                 (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT))
>>                                 this.setOption(StandardSocketOptions.SO_REUSEPORT,
>>                                 false);
>>
>>                                   , but at least it is explicit.
>>
>>                                 Q: not all MS constructors document
>>                                 that SO_REUSEPORT is set, but
>>                                 they should, right? This seems to
>>                                 have slipped past during 6432031
>>                                 [1].
>>
>>                                 -Chris.
>>
>>                                 [1]https://bugs.openjdk.java.net/browse/JDK-6432031
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160929/335d1656/attachment-0001.html>

From chris.hegarty at oracle.com  Thu Sep 29 08:21:10 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 29 Sep 2016 09:21:10 +0100
Subject: RFR 8153674: Expected SocketException not thrown when calling
	bind() with setReuseAddress(false)
In-Reply-To: <b704d8d3-9d44-138a-5c4a-dfa57f9bea53@oracle.com>
References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com>
	<f97a4d87-c358-cfc7-1107-987545bbc41a@oracle.com>
	<cd9dd1ad-e2b2-7740-a343-4243a3b13148@oracle.com>
	<06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com>
	<1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com>
	<56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com>
	<b863d84f-5a18-973a-c07c-63099ec33f3d@oracle.com>
	<0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com>
	<2a451385-ce41-dd15-a21c-b495f805a347@oracle.com>
	<850bd3be-1917-a697-8298-c26da68a0065@oracle.com>
	<9ACD5B67AAC5594CB6268234CF29CF9AA5137216@ORSMSX113.amr.corp.intel.com>
	<2AFB39BF-AB16-4DFA-BAF8-02FE1E84C0FA@oracle.com>
	<b704d8d3-9d44-138a-5c4a-dfa57f9bea53@oracle.com>
Message-ID: <3D441FDE-621D-422D-8826-5A978D39FC38@oracle.com>


> On 29 Sep 2016, at 09:16, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi All,
> 
> Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8153674/webrev0.1/index.html). I had removed the SO_REUSEPORT & spec from constructor.

Thank you Vyom, this looks good to me.

-Chris.

> Thanks,
> 
> Vyom
> 
> On Thursday 29 September 2016 01:38 AM, Chris Hegarty wrote:
>> Thank you Lucy,
>> 
>> We?ll proceed with removing the setting of SO_REUSEPORT from the
>> MulticastSocket constructor and spec.
>> 
>> -Chris.
>> 
>>> On 28 Sep 2016, at 20:02, Lu, Yingqi <yingqi.lu at intel.com> wrote:
>>> 
>>> Hi Vyom,
>>>  
>>> Thank you very much checking with us.
>>>  
>>> We agree that SO_RESUEADDR and SO_REUSEPORT behave the same way for MulticastSocket. There is no need to check and enable SO_REUSEPORT for this particular type of socket. SO_REUSEADDR is sufficient.
>>>  
>>> Thanks,
>>> Lucy
>>>  
>>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com] 
>>> Sent: Wednesday, September 28, 2016 1:26 AM
>>> To: Chris Hegarty <chris.hegarty at oracle.com>; Mark Sheppard <mark.sheppard at oracle.com>; net-dev <net-dev at openjdk.java.net>; Kaczmarek, Eric <eric.kaczmarek at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kharbas, Kishor <kishor.kharbas at intel.com>; Aundhe, Shirish <shirish.aundhe at intel.com>; Lu, Yingqi <yingqi.lu at intel.com>
>>> Subject: Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)
>>>  
>>> Hi All,
>>> 
>>> I had off line discussion here at Oracle and we decided  not to override getReuseAddr/setReuseAddr for MulticastSocket. If user wants, he can set the SO_REUSEPORT with "setOption" before bind.
>>> 
>>> For MulticastSocket SO_REUSEADDR&SO_REUSEPORT are semantically equivalent which means either option will be sufficient to indicate that the address&port is reusable. So setting SO_REUSEPORT in constructor is really necessary/required ?
>>> 
>>> I am looking some comments on this from Intel people(they are in mail chain) who did this original change, before we decide how we wants to proceed on this issue.
>>> 
>>> Thanks,
>>> 
>>> Vyom
>>> 
>>>  
>>> On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote:
>>> On 14/09/16 15:53, Mark Sheppard wrote: 
>>> 
>>> 
>>> that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the 
>>> same could have been argued for the original 
>>> invocation of setReuseAddress, by default , in the constructors, which 
>>> is encapsulating, what pereceived as, common or defacto 
>>> practice wrt applying SO_REUSEADDR on mcast sockets at the system level. 
>>> As I understand it, it is generally perceived that SO_REUSEADDR and 
>>> SO_REUSEPORT are semantically equivalent for multicast sockets. 
>>> As such, I think in the case of MulticastSocket, the fact that the 
>>> setRuseAddress() is called in the constructor, it is appropriate 
>>> to set SO_REUSEPORT also when it exists in the OS. 
>>> 
>>> I take your point on the semantics of setReuseAddress in DatagramSocket 
>>> as per its spec. The spec does allude to MulticastSocket. 
>>> As such, the current proposal's changes just lack the appropriate 
>>> javadoc to describe its behavior, and its additional functionality of 
>>> setting SO_REUSEPORT. 
>>> It is not necessary that overridden method should mirror the semantics 
>>> of the base class method. 
>>> If it is accepted that it is generally perceived that SO_REUSEADDR and 
>>> SO_REUSEPORT are semantically equivalent for multicast sockets, 
>>> then it seems appropriate that an overriding setReuseAddress(..) method 
>>> in MulticastSocket can reflect this. 
>>> 
>>> That sounds reasonable. 
>>> 
>>> -Chris. 
>>> 
>>> 
>>> regards 
>>> Mark 
>>> 
>>> 
>>> 
>>> On 14/09/2016 14:58, Chris Hegarty wrote: 
>>> 
>>> One additional remark. 
>>> 
>>> Was it appropriate to update the legacy MC constructors 
>>> to set the new JDK 9 SO_REUSEPORT in the first place? 
>>> This can be achievable, opt-in from new code, by creating 
>>> an unbound MS, setting the option, then binding. 
>>> 
>>> -Chris. 
>>> 
>>> On 14/09/16 14:47, Chris Hegarty wrote: 
>>> 
>>> Mark, 
>>> 
>>> On 14/09/16 14:22, Mark Sheppard wrote: 
>>> 
>>> 
>>> Hi Chris, 
>>>      I don't fully understand your objections to the approach taken. 
>>> Is there a compatibility issue with the addition of the additional 
>>> methods to MulticastSocket? 
>>> 
>>> The concern is with setReuseAddress performing an operation that 
>>> is not clear from the method specification, e.g. from setReuseAddress() 
>>> 
>>>      * Enable/disable the SO_REUSEADDR socket option. 
>>> 
>>> This is no longer accurate. The proposed changes would affect 
>>> SO_REUSEPORT too. 
>>> 
>>> 
>>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT 
>>> option, this has to be done explicitly via setOption at this level of 
>>> abstraction. 
>>> 
>>> Yes, it is a bit odd, but these are legacy classes. I am not opposed 
>>> to adding a new method for this, or something else. I just want to 
>>> avoid future issues and confusion when setReuseAddress is called and 
>>> then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's 
>>> value has changed. setReuseAddress's spec is very clear about what it 
>>> does. 
>>> 
>>> 
>>> MulticastSocket is a subclass of DatagramSocket (that in itself is a 
>>> questionable structuring), and as such 
>>> has specialized behaviour, and part  of that specialization is the 
>>> setting of  the setting SO_REUSEADDR and SO_REUSEPORT 
>>> in its constructors, to enable address reuse semantics, prior to 
>>> binding 
>>> an address. 
>>> 
>>> Understood. Of course, the setting of SO_REUSEPORT is new in 9, 
>>> hence the problem. 
>>> 
>>> 
>>> As part of that specialization, it would seem appropriate that 
>>> MulticastSocket manipulate the SO_REUSEPORT 
>>> option in a consistent way. Adding an overridden setReuseAddress(...) 
>>> method provides that consistency and 
>>> encapsulates the specialized behaviour. 
>>> 
>>> I agree with the abstraction, just not that setReuseAddress should 
>>> be used to achieve it. The name and spec of this method is so 
>>> tied to SO_REUSEADDR. 
>>> 
>>> 
>>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT 
>>> document clearly how to handle the failing scenario, that an 
>>> MulticastSocket 
>>> requires both setReuseAddress() and a setOption call to disable 
>>> reuseaddress semantics on an unbound MulticastSocket ? 
>>> 
>>> That is one option, and the option that I was suggesting as a possible 
>>> alternative. 
>>> 
>>> 
>>> This then raises the question of why have a convenience method, such as 
>>> setReuseAddress() in the first place, when it can be handled 
>>> adequately via the setOption 
>>> 
>>> We are moving away from these option specific getter and setter 
>>> methods, in favor of the more general get/setOption methods, as 
>>> the latter are more adaptable. 
>>> 
>>> If setReuseAddress is to operate on more than SO_REUSEADDR, then 
>>> its spec should be very clear about this. 
>>> 
>>> -Chris. 
>>> 
>>> 
>>> 
>>> regards 
>>> Mark 
>>> 
>>> On 14/09/2016 13:34, Chris Hegarty wrote: 
>>> 
>>> Mark, 
>>> 
>>> On 14/09/16 13:23, Mark Sheppard wrote: 
>>> 
>>> 
>>> Hi Chris, 
>>>     so are you accepting that it is correct to add the overridden 
>>> methods in MulticastSocket and that these need 
>>> appropriate javadoc ? 
>>> 
>>> I think we need these, but they should just call their super 
>>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would 
>>> exist solely as a place to locate guidance, or a note, that one 
>>> will likely want to set SO_REUSEPORT too. 
>>> 
>>> 
>>> or are you advocating pushing the handing of the SO_REUSEPORT into 
>>> the 
>>> base DatagramSocket class ? 
>>> 
>>> It is already there. I am not proposing to change this. 
>>> 
>>> 
>>> It is not clear how your code changes fit in the proposed fix i.e. 
>>> the 
>>> explicit setting of the option to false? 
>>> 
>>> My proposal is an alternative. It is not related to the current 
>>> webrev. 
>>> 
>>> 
>>> With the current proposed changes then I think it would be 
>>> sufficient to 
>>> invoke setReuseAddress(true) in MulticastSocket constructors 
>>> rather than 
>>> 
>>>         // Enable SO_REUSEADDR before binding 
>>>         setReuseAddress 
>>> <https://java.se.oracle.com/source/s?defs=setReuseAddress&project=jdk9-dev>(*true*); 
>>> 
>>> 
>>> 
>>> 
>>>         // Enable SO_REUSEPORT if supported before binding 
>>>         *if* (supportedOptions 
>>> <https://java.se.oracle.com/source/xref/jdk9-dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedOptions>().contains 
>>> 
>>> 
>>> 
>>> <https://java.se.oracle.com/source/s?defs=contains&project=jdk9-dev>(StandardSocketOptions 
>>> 
>>> 
>>> 
>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>> 
>>> 
>>> 
>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>)) 
>>> 
>>> 
>>> { 
>>>             *this*.setOption 
>>> <https://java.se.oracle.com/source/s?defs=setOption&project=jdk9-dev>(StandardSocketOptions 
>>> 
>>> 
>>> 
>>> <https://java.se.oracle.com/source/s?defs=StandardSocketOptions&project=jdk9-dev>.SO_REUSEPORT 
>>> 
>>> 
>>> 
>>> <https://java.se.oracle.com/source/s?defs=SO_REUSEPORT&project=jdk9-dev>, 
>>> 
>>> 
>>> *true*); 
>>>         } 
>>> 
>>> 
>>> as the overridden setReuseAddress takes care of SO_REUSEPORT 
>>> 
>>> Yes, this is what Vyom has proposed, in the webrev. 
>>> 
>>> I would like to explore an alternative, so see what it would look 
>>> like. 
>>> 
>>> -Chris. 
>>> 
>>> 
>>> 
>>> regards 
>>> Mark 
>>> 
>>> On 14/09/2016 11:43, Chris Hegarty wrote: 
>>> 
>>> Vyom, 
>>> 
>>> On 11/09/16 08:01, Vyom Tewari wrote: 
>>> 
>>> Hi All, 
>>> 
>>> Please review the below code change. 
>>> 
>>> Bug        : https://bugs.openjdk.java.net/browse/JDK-8153674 
>>> 
>>> Webrev  : 
>>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html 
>>> <http://cr.openjdk.java.net/%7Evtewari/8153674/webrev0.0/index.html>
>>> 
>>> 
>>> This change override the "get/setReuseAddress"  for MulticaseSocket 
>>> and 
>>> will abstract with both reuse attributes(SO_REUSEADDR & 
>>> SO_REUSEPORT). 
>>> 
>>> This issue arises since the changes for 6432031 "Add support for 
>>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if 
>>> the available. So setting setReuseAddress(false) alone is no longer 
>>> sufficient to disable address/port reuse, one must also set 
>>> SO_REUSEPORT to false. 
>>> 
>>> I would be really nervous about changing set/getReuseAddress, 
>>> without 
>>> at least updating the javadoc to indicate that it is now, for MS, 
>>> operating on two socket options.  Although, I do have sympathy 
>>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when 
>>> dealing with multicasting. 
>>> 
>>> An alternative, maybe; Since the MS constructors document that 
>>> SO_REUSEPORT will be set, where available, maybe a javadoc note 
>>> on the set/getReuseAddress methods would be sufficient, that 
>>> indicates that StandardSocketOptions#SO_REUSEPORT may also need 
>>> to be set to have the desired effect? 
>>> 
>>> If so, then code would have to: 
>>> 
>>>     setReuseAddress(false); 
>>> 
>>>     if 
>>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT)) 
>>> this.setOption(StandardSocketOptions.SO_REUSEPORT, false); 
>>> 
>>>   , but at least it is explicit. 
>>> 
>>> Q: not all MS constructors document that SO_REUSEPORT is set, but 
>>> they should, right? This seems to have slipped past during 6432031 
>>> [1]. 
>>> 
>>> -Chris. 
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031
>>>  
>>>  
>>>  
>>>  
>> 
> 


From chris.hegarty at oracle.com  Thu Sep 29 11:40:00 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 29 Sep 2016 12:40:00 +0100
Subject: RFR(S): 8166850: No runtime error expected after calling
	NET_MapSocketOption
In-Reply-To: <4ea21b3c8a1f47418058004c31e46d72@DEWDFE13DE11.global.corp.sap>
References: <4ea21b3c8a1f47418058004c31e46d72@DEWDFE13DE11.global.corp.sap>
Message-ID: <CAB0A886-3D7E-424E-83D1-8657B33F10D0@oracle.com>

On 28 Sep 2016, at 16:39, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
>  
> during my work on exception sites in the JDK, I spotted another minor place that should be fixed. In the Windows native implementations of DualStackPlainDatagramSocketImpl and DualStackPlainSocketImpl, there are calls to evaluate OS API errors after unsuccessful return of NET_MapSocketOption where this should not be done. Please review my fix. I also took the opportunity to clean up some indentations.
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166850
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166850.0/

The changes, and cleanup, look fine.

-Chris.

From christoph.langer at sap.com  Thu Sep 29 13:05:53 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 29 Sep 2016 13:05:53 +0000
Subject: RFR(S): 8166850: No runtime error expected after calling
	NET_MapSocketOption
In-Reply-To: <CAB0A886-3D7E-424E-83D1-8657B33F10D0@oracle.com>
References: <4ea21b3c8a1f47418058004c31e46d72@DEWDFE13DE11.global.corp.sap>
	<CAB0A886-3D7E-424E-83D1-8657B33F10D0@oracle.com>
Message-ID: <a6fba8f05bc04cf394d9df7481493a29@DEWDFE13DE11.global.corp.sap>

Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/153b4781adcc

Thanks, Chris, for reviewing.

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Donnerstag, 29. September 2016 13:40
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: RFR(S): 8166850: No runtime error expected after calling
> NET_MapSocketOption
> 
> On 28 Sep 2016, at 16:39, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> >
> > Hi,
> >
> > during my work on exception sites in the JDK, I spotted another minor place
> that should be fixed. In the Windows native implementations of
> DualStackPlainDatagramSocketImpl and DualStackPlainSocketImpl, there are
> calls to evaluate OS API errors after unsuccessful return of
> NET_MapSocketOption where this should not be done. Please review my fix. I
> also took the opportunity to clean up some indentations.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8166850
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166850.0/
> 
> The changes, and cleanup, look fine.
> 
> -Chris.