On 18/04/2020 00:13, Ivanov, Vladimir A wrote:
Hello everyone,
I would like to add support for the Application Device Queue (ADQ) technology
to the JDK.
The JBS entry and webrev were created for this improvement:
JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
Webrev: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.00/
Please let us know your feedback and comments for this enhancement.
Just to put more context on this. Vladimir brought this to nio-dev in
March with some background and initial proposed it as a standard socket
option [1]. A socket option that allows an application to split incoming
flows based on their receive queue is very Linux specific so we
suggested it should be in the JDK-specific ExtendedSocketOptions API
with the other non-standard socket options.
net-dev is the right mailing list to progress this and get a sponsor
(maybe Sandhya Viswanathan will do it?). We can probably drop
core-libs-dev from the this one.
Just a few comments on the current webrev:
The API docs in the webrev is a good start but will need to be fleshed
out as it uses several terms such as "device queue", "last frame", "Rx
queue" without any definition. One important point that we will need to
be covered is that it's a read-only socket option so the docs will need
to specify the exception that will be thrown when trying to set it. From
a quick look at the implementation then it appears to fall through to
InternalError so that might need to be fixed. It will also be important
to document the socket types and where in their lifecycle (listening,
connected) that the socket option can be used.
Will SO_INCOMING_NAPI_ID be defined in a header file? It probably needs
#ifndef to avoid the hardcoded value when building on distributions that
define it. A passing comment is that native methods static methods so
"unused" is a jclass.
Tests. Read-only socket options might trip up on existing tests in the
jdk_net or jdk_nio test groups that enumerate all socket options and
exercise get and set on each one. The proposed test will probably go
several iterations to get to something that is maintainable. It will
also need to be extended to exercise SocketChannel, ServerSocketChannel
and more.
-Alan
[1] https://mail.openjdk.java.net/pipermail/nio-dev/2020-March/007109.html
