Ugh... sorry. I somehow had an impression that the problem is in localhost to 127.0.0.1 matching. D. On Jun 8, 2013 5:29 PM, "Robert Muir" <[email protected]> wrote:
> 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] >> >> >
