adding rsockets support into JDK
yingqi.lu at intel.com
Fri Nov 23 21:38:04 UTC 2018
I am not sure when IPv4-mapped addresses will be supported in rsocket.
Based on the suggestions earlier this week, I completed the version 19 of the patch at http://cr.openjdk.java.net/~ylu/8195160.19
Inside that, I have done:
1. Totally removed IPv6 support for rsocket, and removed -Djava.net.preferIPv4Stack=true in all the test cases.
2. Instead of using "librdmacm.so", "librdmacm.so.1" is used for the library name.
3. Caught java.lang.ExceptionInInitializerError when rdma library is not installed in the system. A UOE is thrown instead.
4. In the tests, modified both RsocketTest.java RdmaSocketsTest.java to double check UOE on all the platforms when rdma library is not installed.
Then, I just saw your emails on IPv6 handling :-) I can see both advantages and disadvantages of either keeping or removing IPv6 support for rsocket, and totally fine whichever direction you decide. If we want to use protocol family approach, would you please point me to an example so that I can follow?
>From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>Sent: Friday, November 23, 2018 9:39 AM
>To: Chris Hegarty <chris.hegarty at oracle.com>; Lu, Yingqi <yingqi.lu at intel.com>
>Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; nio-
>dev at openjdk.java.net; Aundhe, Shirish <shirish.aundhe at intel.com>; Kaczmarek,
>Eric <eric.kaczmarek at intel.com>
>Subject: Re: adding rsockets support into JDK
>On 23/11/2018 17:23, Chris Hegarty wrote:
>> Please let’s agree to avoid dual-socket hacks at all costs. I have
>> firsthand experience of this from working with older Windows platforms.
>> If IPv4-mapped IPv6 address support is lacking or not on the relative-
>> near horizon ( for the particular rsocket implementation being used ),
>> then maybe the API factory methods should accept a `ProtocolFamily` to
>> selectively create a socket of a particular family. That way both IPv6
>> and IPv4 will be supported, just not in the same socket.
>I think you may have mis-read my mail as I'm not suggesting we go the two
>sockets route. This needs to be fixed in the rsockets module but the timeframe on
>that isn't clear at this point. Yes, we could introduce factory methods that take a
>protocol family like we did in DatagramChannel (for multicast case) but it puts a
>burden on that usages that we also want to avoid.
More information about the nio-dev