Hi Chris,

On 10/10/2016 9:43 AM, Chris Hegarty wrote:

I addressed all, or most, of your comments in the following

 1) Refactored out the use of sun.nio.ch in the test library,
   so that a reduced number of tests need their @modules tag
   updated. ( @modules support with test library usage it a
   pain )
It would be ok to put the modules java.base/sun.nio.ch dependency in the test/java/rmi/TEST.properties.
Or perhaps in a new test/java/rmi/activation/TEST.properties

(I would probably move many of the @modules in individual tests there.
Though it is cleaner to have only the ones that are really needed by each test.)

Can the @build dependencies also go in TEST.properties using lib.build =

 2) Use Boolean.getBoolean to retrieve the new property

 3) fix typos and remove stray debugging statements


 line 60:  ephemeralPort could be removed; (unused)

line 106: the string "java.nio.channels.spi.SelectorProvider=RMIDSelectorProvider" should be
    a static and used the JavaVM.  (similar to RMID.EPHEMERAL_MSG)

I'm vaguely not very comfortable with scraping the port number off stdout
and the inherited channel pieces seem like a lot of moving parts.

Right, I was a little uneasy with this too, to being with, but
it has grown on me ( since it appears stable and reliable in
all my builds and tests ). Also the surface area of the code
change is very small, and the inherit channel mechanism is well
specified and stable.

ok, lets give it a try.

Thanks, Roger


p.s.  Anyother idea
I assume not all platforms can allow separate processes to open server
sockets to the same port.
If so, we would just have the client allocate a port (0), mark it
non-exclusive and keep it open
while passing the port number to RMID. Only after RMID is started close
the allocating socket.

I believe Stuart did look at this in some detail a while back [1], and
it was somewhat dismissed because of the lack of cross platform support
for SO_REUSEPORT. Maybe things have move on, but I don't think so?

The use of inherit channel is somewhat akin to loading an agent into
the target, but more straightforward.

What do others think, that will have to maintain these tests? I don't
want to make them every harder to maintain. Hamlin's approach is still
on the table too.


[1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016251.html

Reply via email to