Could we add a simple test that verifies if a connection like what you've described can be made? It could timeout after a short while in case there's a black hole or something but at least we'd know a connection is feasible (or not) on a given machine.
Dawid On Sat, Jun 8, 2013 at 4:02 PM, Robert Muir <[email protected]> wrote: > I think it would be hard to catch this bug automatically. > > again the bug is when someone has something like this in /etc/hosts > > 127.0.0.1 localhost > ::1 localhost > > And then you ask a server to bind *only* and *explicitly* to 127.0.0.1, but > client code is set to connect to "localhost". > > I think if you are consistent it will work either way... > > > On Sat, Jun 8, 2013 at 9:57 AM, Dawid Weiss <[email protected]> > wrote: >> >> Uwe -- could this be integrated in security manager's checkConnect? >> >> Dawid >> >> On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <[email protected]> >> wrote: >> > I suspect it's one of those thing that will creep back in as code >> > changes, using localhost seems harmless enough (but we know it >> > isn't).... >> > >> > Is there any chance the precommit stuff could be enhanced to check? >> > Maybe only in the test code? >> > >> > On Sat, Jun 8, 2013 at 9:03 AM, Robert Muir <[email protected]> wrote: >> >> I think this is absolutely related. But i did a quick search for >> >> "localhost" >> >> in the source tree and found occurrences in src/ and test/ related >> >> code... >> >> if the server is binding ONLY to 127.0.0.1, but the client is trying to >> >> connect to "localhost", it could be causing issues with those tests on >> >> certain configurations (at least OS X + java6) >> >> >> >> On Sat, Jun 8, 2013 at 8:57 AM, Erick Erickson >> >> <[email protected]> >> >> wrote: >> >>> >> >>> Dear Lord that's obscure! If I remember right, Uwe advocated using >> >>> 127.0.0.1 >> >>> at one point, is this related? >> >>> >> >>> Anyway, I'm glad you were able to track this down! >> >>> >> >>> Erick >> >>> >> >>> On Sat, Jun 8, 2013 at 8:49 AM, Robert Muir <[email protected]> wrote: >> >>> > Hello, >> >>> > >> >>> > As you know, the jetty test in lucene's replicator module would fail >> >>> > in >> >>> > non-reproducible ways, only on Mac OS X, and only on java6. Finally >> >>> > we >> >>> > got >> >>> > to the bottom of this: >> >>> > https://issues.apache.org/jira/browse/LUCENE-5037 >> >>> > >> >>> > The basic problem is: the server would start on 127.0.0.1, but the >> >>> > client >> >>> > would connect to localhost. At least this one configuration (OSX + >> >>> > java6) >> >>> > behaves wierd on a dual-stack ipv4/ipv6 system, it seems to >> >>> > round-robin >> >>> > thru >> >>> > the 3 entries for localhost in /etc/hosts (127.0.0.1, ::1, and >> >>> > link-local >> >>> > ipv6). This means the test would fail if the resolver picked an ipv6 >> >>> > one. >> >>> > >> >>> > So the fix was to just use 127.0.0.1 for both server and client in >> >>> > the >> >>> > test. >> >>> > >> >>> > I wonder if the same bug impacts other tests (e.g. solr jetty tests) >> >>> > using >> >>> > jetty. >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
