My bad. I'll look into it and make the test retrieve the port from the correct place.
The ITs are disabled in the builds for now. I'm trying to get the builds back to a place where we take notice when they're failing. Note that we are no longer getting separate emails for each module. Billie On Sep 13, 2013 4:20 PM, "Michael Berman" <[email protected]> wrote: > And along the same lines as that test... ReadWriteIT.sunnyDay() relies on > MAConfig's mergePropWithRandomPort to assign a monitor port. However, > mergePropWithRandomPort doesn't actually assign a random port, it assigns > zero, assuming a random port will get assigned when the socket is bound. > This works fine, except that the test then pulls the port out of the > config and tries to connect to it, which seems like it should never work > since it's always :0. Does this work for other people? It seems to be > working on Jenkins, so does anyone know what I'm missing? > > > On Fri, Sep 13, 2013 at 4:03 PM, Michael Berman <[email protected]> wrote: > > > Is anyone else seeing issues in this test (on master HEAD as of an hour > > ago)? Inspecting the code, I can't see how it would ever pass, but since > > Jenkins is green, I must be missing something... > > > > In MiniAccumuloCluster:371, config.shouldRunGC() is always false, so > > gcProcess is null. > > > > MiniAccumuloCluster.getProcesses() always adds its GC to its result map, > > even though in this case it's null. > > > > RestartIT.restartMasterRecovery() calls MiniAccumuloCluster.killProcess() > > on every reference returned by getProcesses, and > ProcessReference.equals() > > will NPE if it's wrapping a null process. > > > > It seems like the fix should be to exclude the GC from getProcesses if it > > doesn't exist, but I'm hesitant to make this change until I understand > why > > I'm the only one who sees this issue. > > >
