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] > >
