These problems stem from a dirty testing environment occupying the default port, which this test wants to use. I have a pull request open to ignore the test when the default port is not available.
On the one hand, an ignored test is essentially dead code. If the test is consistently skipped and not only occasionally skipped, it's not informing us of anything. But on the other hand, a flaky test ends up being more or less ignored and its errors end up being discarded as general flakiness. I'd favor the "assume X or skip" route over marking a test flaky, but that will require some diligence on our part to make sure these tests do end up eventually running. Pull request #771: https://github.com/apache/geode/pull/771 On Thu, Sep 14, 2017 at 8:51 AM, Kirk Lund <kl...@apache.org> wrote: > These tests have been failing intermittently in the integrationTest target > for over a week. I'm going to add the category FlakyTest to these tests. > See GEODE-3426. > > org.apache.geode.rest.internal.web.RestServersJUnitTest > testGet FAILED > org.junit.ComparisonFailure: expected:<[200]> but was:<[404]> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance( > NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance( > DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.rest.internal.web.RestServersJUnitTest.testGet( > RestServersJUnitTest.java:49) > > org.apache.geode.rest.internal.web.RestServersJUnitTest > > testServerStartedOnDefaultPort FAILED > org.json.JSONException: Value <html> of type java.lang.String cannot be > converted to JSONArray > at org.json.JSON.typeMismatch(JSON.java:108) > at org.json.JSONArray.<init>(JSONArray.java:85) > at > org.apache.geode.rest.internal.web.GeodeRestClient. > getJsonArray(GeodeRestClient.java:99) > at > org.apache.geode.rest.internal.web.RestServersJUnitTest. > testServerStartedOnDefaultPort(RestServersJUnitTest.java:55) >
