adding rsockets support into JDK

[Lu, Yingqi]

Hi Alan/Chris,

Here is the version 26 of the patch: http://cr.openjdk.java.net/~ylu/8195160.26/

In this version, I first applied the following patches from Chris:

http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.1/

http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.2/

http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.3/

http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.4/

http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.5/

http://cr.openjdk.java.net/~chegar/rsocket/webrev.25.6/

Then, following Alan's suggestion, I made the rsocket to be non-blocking at the creation time for socket channels. I modified accept function from RdmaServerSocketChannelImpl, and connect/read/write functions from RdmaSocketChannelImpl to simulate blocking. Please let me know if this is a reasonable approach. I tested the patch with all 23 JTreg test cases and they all pass (I commented out all 12 tests for non-blocking connect cases in IOExchanges.java given issue #2 is still open)

I also sent an email to Sean on the Linux kernel fix for issue #1. Once I get a reply from him, I will let you both know.

Thanks,
Lucy

>-----Original Message-----
>From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>Sent: Tuesday, December 18, 2018 6:15 AM
>To: Lu, Yingqi <yingqi.lu at intel.com>
>Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net;
>Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Aundhe, Shirish
><shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com>
>Subject: Re: adding rsockets support into JDK
>
>
>
>> On 17 Dec 2018, at 19:07, Lu, Yingqi <yingqi.lu at intel.com> wrote:
>>
>> I already discussed with Sean on this specific issue. He mentioned that even he
>can propose a fix to the kernel librdmacm module, it would take years to get into
>majority of the distros. I would recommend to emulate the behavior inside JDK
>and make use of it.
>
>Sure, but it would be good to have some forward movement on this, so that the
>Java implementation can remove the workaround at some future point.
>
>-Chris.