adding rsockets support into JDK

[Lu, Yingqi]

Hi Chris,

Thank you so much for the help on this work. Really appreciate!!

Just to let you know. I also tried your IOExchanges.java test on webrev.25. I commented out the test 7-12 and 7a-12a as they relate to issue #2. I ran the test for 10000 loops and I do not see any failures or errors.

I will apply all your patches to my local repository now.

I remember there is one more open item from your comment earlier in addition to issue #2 -- the null binding issue. Details are listed below. To resolve this issue, we might need to change some JDK public APIs either at java.net.Socket or java.netInetXAddress. I am looking forward to your guidance here as well :-)
----------------------------------------------------------------------------------------------
3) Handling of null binding, automatically assigned address.

  Handling of null binding is a bit tricky now that we have protocol
  family support. The correct InetXAddress "any local address" needs to
  be created. I added a test and a little refactoring. If you run the
  test without any source changes you will be able to see the issues.

    https://cr.openjdk.java.net/~chegar/rsocket/webrev.23.3/
    
  Note: There is still an open issue, ToDo, with java.net.Socket. You
  can see this by a small comment in the test. I'll revisit this later. 
---------------------------------------------------------------------------------------------

Thanks,
Lucy

>-----Original Message-----
>From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>Sent: Friday, December 14, 2018 9:47 AM
>To: Lu, Yingqi <yingqi.lu at intel.com>
>Cc: Aundhe, Shirish <shirish.aundhe at intel.com>; nio-dev at openjdk.java.net;
>Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kaczmarek, Eric
><eric.kaczmarek at intel.com>
>Subject: Re: adding rsockets support into JDK
>
>Lucy,
>
>> On 13 Dec 2018, at 17:59, Lu, Yingqi <yingqi.lu at intel.com> wrote:
>>
>> Hi Chris/Alan,
>>
>> Here is the version 25 of the patch:
>> http://cr.openjdk.java.net/~ylu/8195160.25/
>
>Some further comments.
>
>1) test/jdk/jdk/net/RdmaSockets/rsocket/Selector/Connect.java
>
>  This test unnecessarily creates a thread for each connection.
>  http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.1/
>
>2) Additional test coverage for basic switching of blocking state.
>
>  http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.2/
>
>3) I think your work-around for Issue #1 is probably ok. I refined it a
>  little so avoid accessing the flags unless necessary. I think this may
>  be slightly more efficient, since the typical non-blocking usage will
>  be preceded by a select/rpoll.
>
>  src/jdk.net/linux/native/libextnet/LinuxRdmaSocketDispatcherImpl.c
>  http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.3/
>
>4) LinuxRdmaSocketDispatcherImpl.java
>
>  While reading the code I noticed an odd/stray unused `close` method. I
>  think it should be removed to avoid confusion ( it confused me ).
>
>  http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.4/
>
>5) test/jdk/jdk/net/RdmaSockets/rsocket/SocketChannel/IOExchanges.java
>
>  I updated this test to ensure that all selectors are now closed ( they
>  were not all closed consistently in the previous version ).
>
>  http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.5/
>
>  What is nice about this test is that the *_BConn_* method verify the
>  changes in 3 above ( for Issue #1 ). I still wanna add scatter/gather
>  variants ( its on my TODO list ).
>
>  For now, until Issue #2 is resolved, then just comment out the `@Test`
>  from the twelve *_NBConn_* methods ( they currently fail, since they
>  verify the yet-to-be-fixed Issue #2 ). It is on my list to look into
>  fix this issue too.
>
>6)
>test/jdk/jdk/net/RdmaSockets/rsocket/SocketChannel/CloseDuringWrite.jav
>a
>
>  Just some cleanup in this test.
>  http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.6/
>
>  The reason I'm doing some of this cleanup is that I see infrequent
>  failures in a few of these tests ( about 1 failure in ever 30 or so
>  runs ).
>
>
>That's my patch queue empty, for now. I hope that applying these patches is
>not too onerous. They are mostly review comments, and I hope to be getting
>to the end of this soon.
>
>-Chris.