rsocket Issue #2

[Hefty, Sean]

I have a patch to address the connection progress issue.  I've opened a pull request against the upstream rsocket code here:

https://github.com/linux-rdma/rdma-core/pull/506

I've included a test app as part of the pull request.  But if you can verify that the changes work with your tests, that would be great.

I believe with this change, the problem you were seeing with a blocking rrecv() call returning EAGAIN should no longer occur.

There is still no fix for the rpoll() issue reported below.  I'm not exactly sure where the problem is that causes that yet.

- Sean


> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Wednesday, February 13, 2019 10:00 AM
> To: Lu, Yingqi <yingqi.lu at intel.com>; nio-dev at openjdk.java.net; Hefty, Sean
> <sean.hefty at intel.com>
> Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kaczmarek, Eric
> <eric.kaczmarek at intel.com>; Aundhe, Shirish <shirish.aundhe at intel.com>
> Subject: rsocket Issue #2
> 
> Hi Sean, Lucy,
> 
> In an attempt to work-around issue #2 (non-blocking connect not making
> progress, reported in [1] ), I have run into a separate issue with
> `rpoll`. I think it is a bug, and it will make working-around issue #2
> much more difficult ( maybe impracticable ).
> 
> The behaviour I observe is that, if more than one thread is blocked in
> a `rpoll` call ( with the same socket and events), and the event is
> triggered, then only one thread ( rpoll ) will wakeup. I've put together
> a native test:
>    http://cr.openjdk.java.net/~chegar/rsocket/testBipollar.c
> 
> This is an issue for the Java API that allows a channel to be registered
> with more than one selector. It is also a possible issue with a selector
> racing with finishConnect. These scenarios are not all that common, but
> still possible.
> 
> The `rpoll` behaviour I observe is clearly different than regular
> `poll` ( which will wake up all waiters ). Is this a bug, or expected
> behaviour of the thread-less rsocket implementation?
> 
> -Chris.
> 
> [1]
> https://mail.openjdk.java.net/pipermail/nio-dev/2018-December/005651.html