What do you mean? the bug is ours, if we only bind to a specific address (127.0.0.1) and then connect to "localhost", assuming it will resolve to 127.0.0.1
There is nothing to "detect". It would be just as bogus if i started up a server on 74.125.228.103, and then assumed that anyone typing "google.com" could connect to it, because "google.com" maps to like 10 or 11 addresses. As far as the jvm differences, i have no idea why the resolver behavior is different on 1.6 for OS X. maybe the previous behavior was a bug dealing the order of names that map to multiple addresses. But it doesnt matter anyway. Again the bug is ours by making these assumptions. 1.6: InetAddress.getAllByName(localhost)=[localhost/192.168.57.17, localhost/fe80:0:0:0:a00:27ff:fec7:f28b%4] InetAddress.getByName(localhost)=localhost/192.168.57.17 1.7: InetAddress.getAllByName(localhost)=[localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1, localhost/fe80:0:0:0:0:0:0:1%1] InetAddress.getByName(localhost)=localhost/127.0.0.1 On Sat, Jun 8, 2013 at 11:04 AM, Dawid Weiss <[email protected]>wrote: > 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] > >
