RFR 8005226: TEST_BUG: java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java fails intermittently
Stuart Marks
stuart.marks at oracle.com
Wed Mar 4 21:02:13 UTC 2015
On 3/4/15 11:14 AM, Chris Hegarty wrote:
>
>> On 4 Mar 2015, at 18:10, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Instead of creating a socket factory for this purpose, this test can use RMI's test library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this uses the now disfavored "getUnusedRandomPort" pattern, but it can (and should) be changed to avoid this. In, fact, passing 0 will work, though it could use its own socket factory if necessary. (It would be good to keep this knowledge within the test library.)
>
> Sorry, I’m confused. Are you suggesting that I change TestLibrary.createRegistryOnUnusedPort to use a socket factory, similar to the changes in the webrev? Or are you saying that the TestLibrary already supports bind to an ephemeral port and subsequently disclosing that port?
Sorry, there are several pieces moving around here and a couple (or more) layers
of technical debt.
1) The test itself should call TestLibrary.createRegistryOnUnusedPort() and
TestLibrary.getRegistryPort(), since those are the abstractions the test library
is attempting to provide. Unfortunately, doing this by itself doesn't fix the
problem, since the test library itself calls getUnusedRandomPort().
2) TestLibrary.createRegistryOnUnusedPort() can be changed to call
LocateRegistry.createRegistry(0), which seems to be permitted by the API and the
implementation, and which works in my limited testing. But it would need to be
tested more thoroughly, and if for some reason it doesn't work, it could use the
socket factory technique or some other technique.
3) Other RMI tests that create registries will need to be retrofitted to use the
test library in this way. Probably beyond the scope of this changeset.
I'd prefer not to have the socket factory stuff added to the test, since it'd
just have to be ripped out later when better ephemeral port handling is
supported by the test library.
4) If a quick fix is necessary, the test could call
LocateRegistry.createRegistry(0) itself (assuming this works well) if you don't
want to take on the modification of the test library, but this too would have to
be changed eventually.
So I'd like to see one of the following:
- both (1) and (2); or
- just (4)
Your option, depending on how much you want to take on.
s'marks
>
> -Chris.
>
>> The actual port number in use can be fished out of the registry implementation by calling TestLibrary.getRegistryPort().
>>
>> s'marks
>>
>>
>> On 3/4/15 7:01 AM, Chris Hegarty wrote:
>>> This is a small, test only, review request to fix an intermittently failing test.
>>>
>>> There is an inherent race, and possible failure, following the
>>> getUnusedRandomPort pattern. This test can be modified to use a custom socket
>>> factory, supporting listening on an ephemeral port, without changing the
>>> behavior of the test.
>>>
>>> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>>>
>>> -Chris.
>
More information about the core-libs-dev
mailing list