Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Tue Apr 17 09:00:23 UTC 2012
- Previous message: Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing
- Next message: Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 16/04/2012 19:34, Darryl Mocek wrote:
Ah, yes, with -agentvm specified, many tests fail. I'll have to add java/rmi and sun/rmi back to the list of tests which must be run in othervm mode and I should probably add back othervm to the tests I removed it from. At least with the port conflict fix, we can run the tests concurrently and they will run much faster. Yes, it's a good first step and I look forward to getting much better through-put of these tests.
I see the logic in TestLibrary to choose a random port and I'm just wondered if you considered doing LocaleRegistry.createRegistry(0) so that the registry binds to an ephemeral port. It would mean that TestLibrary would need to get to the transport endpoint and port but it would avoid having to try multiple ports. I would have like to use LocaleRegistry.createRegistry(0), but I don't see a way to get the port number once the registry is created, which is required. I originally tried creating a TestLocaleRegistry which extends LocateRegistry, with a getPort() method, but this didn't work either. I don't think there is an API to get the endpoint (Peter Jones, any ideas?) so it may require TestLibrary to use reflection or sun.* code to get it. Another sleazy suggestion is that it's in toString output and TestLibrary would provide method to get the port that wouldn't require all the tests to depend on it.
-Alan
- Previous message: Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing
- Next message: Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]