Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 10 Oct 2007 16:29:40 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: solr-dev@lucene.apache.org
Subject: Re: Solr nightly build failure
In-Reply-To: <470D5500.7050701@gmail.com>
Message-ID: <Pine.LNX.4.62.0710101622490.7470@radix.cryptio.net>
References: <200710100810.l9A8AhpI022622@lucene.zones.apache.org>
 <1C4E74F251F70F44A9EB009DB00A211DB1490D@C12-E2K3-MBOX02.cnet.cnwk>
 <6F36BDD2-A1EB-4FA2-B20F-C06A26690002@gmail.com> <470D5500.7050701@gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: For the jetty based tests, perhaps we should just give a warning if it tries
: to bind a port and can't -- in that case the tests are not called, but we
: still have them for the normal dev case where we can bind the port.

according to the hudson failure logs,the problem hasn't been binding to 
the port (as in: the server starting up) it's the client not being able to 
onnect to the port in 5ms. (at least: that's hte cause of hte last 6 
failures)

given that these tests are running on a virtual server with *lots* of 
other virtual servers, it doesn't seem that odd that it might take 5ms 
before the connection is initialized  

i seem to recall some discussion about increasing that timeout, and 
deciding that it was a bad idea because in the "normal" case it's usually 
short, but at the very least lets make it a config option or something so 
the test can specify a large value.  (it doesn't even have to be an easy 
to chnge config option, it could even be a system property for now, just 
so we can try chaning it in the nightly build environment and see if it 
makes things better.


i'd rather not kill a "good" test just because it fails in some situations 
-- that tells me that either the test or the code being tested doesn't 
handle that situation very well.  if the test isn't waiting long enough 
for the server to start up before sending requests, then we should fix the 
test -- if the client isn't waiting long enough fortheserver to connect, 
we should improve the client.


-Hoss