RFR: JDK-8068721 - RMI-IIOP communication fails when ConcurrentHashMap is passed to remote method

Alan Bateman Alan.Bateman at oracle.com
Tue Mar 24 14:08:44 UTC 2015


On 24/03/2015 11:11, Mark Sheppard wrote:
> Hi Alan,
>    thanks for the feedback.
>
> WRT test location, I followed what is already in place i.e. 
> javax/rmi/ssl had an existing test
> so as RMI-IIOP falls under javax/rmi/PortableRemoteObject, placing the 
> test in this grouping seemed reasonable.
> It's no bother to place it elsewhere if you wish.
To date then the directories containing the CORBA and RMI-IIOP tests 
have been in the jdk_other group. I think it would be best not to have 
them split between two groups. Adding this to jdk_other should do it:

javax/rmi \
-javax/rmi/ssl

>
> WRT 1050,  this is a conundrum, and there doesn't seem to be a 
> reliable way of obtaining a port to absolutely avoid a clash.
> This is the orbd's standard port.
> There doesn't seem to be a reliable way of obtaining a port to 
> absolutely avoid a clash.
> The test relies on the observation that ephemeral ports on most 
> contemporary platforms are being allocated
> outside the well known and application allocated port ( > 32K ).
> It could use 1060 instead.
> It possible that multiple concurrent  orbd may be running,  but I've 
> run the regression suite many times for this issue, and
> multiple orbd execution hasn't shown up, yet.
You might need to look at the exclusiveAccess.dirs property in TEST.ROOT 
to avoid several tests trying to run orbd at the same time.

Stuart has been battling a bunch of issues in other areas with "address 
already in use" and may have some advice on how to approach this test. I 
do see that orbd can run on other ports and also it might be possible to 
start it via it's com.sun API rather than the launcher.


> :
>
> WRT stubs and ties, I was trying to avoid use of a shell script. A 
> once off generation of stub and tie was
> a handy way to avoid this. I don't think jtreg has an @rmic or @idl 
> similar to @build or @compile?
>
This may be something to add to the testlibrary infrastructure.

-Alan.



More information about the core-libs-dev mailing list