You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Robert Muir <rc...@gmail.com> on 2013/06/08 14:49:49 UTC
FYI: localhost vs 127.0.0.1 in networking-related tests
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.
RE: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Uwe Schindler <uw...@thetaphi.de>.
Unfortunately it's not possible to check this. I already tried to limit LISTEN and ACCEPT to 127.0.0.1, but the security manager also allows listening on 0.0.0.0, independent on what you really do (for bind/listen it does not check the IP at all, only the port -> see docs).
I checked SOLR tests already: Jetty and connections to our Jetties is no issue at all, it binds to 127.0.0.1 only and clients also do. The search hits on "localhost" in the source code were only in comments (we should maybe fix). There are 2 things that bind to "all" interfaces and connect to "localhost" are Zookeeper (we should at least fix this) and Java's horrible serialization/RPC/MBean framework (we cannot fix).
I could extend forbidden-apis to look for string patterns in the constant pool of all checked classes...
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: dawid.weiss@gmail.com [mailto:dawid.weiss@gmail.com] On Behalf
> Of Dawid Weiss
> Sent: Saturday, June 08, 2013 3:58 PM
> To: dev@lucene.apache.org
> Subject: Re: FYI: localhost vs 127.0.0.1 in networking-related tests
>
> Uwe -- could this be integrated in security manager's checkConnect?
>
> Dawid
>
> On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <er...@gmail.com>
> 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 <rc...@gmail.com> 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
> >> <er...@gmail.com>
> >> 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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org For
> >>> additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Dawid Weiss <da...@gmail.com>.
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" <rc...@gmail.com> 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 <dawid.weiss@cs.put.poznan.pl
> > 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 <rc...@gmail.com> 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 <
>> dawid.weiss@cs.put.poznan.pl>
>> > wrote:
>> >>
>> >> Uwe -- could this be integrated in security manager's checkConnect?
>> >>
>> >> Dawid
>> >>
>> >> On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <
>> erickerickson@gmail.com>
>> >> 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 <rc...@gmail.com>
>> 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
>> >> >> <er...@gmail.com>
>> >> >> 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 <rc...@gmail.com>
>> 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: dev-unsubscribe@lucene.apache.org
>> >> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Robert Muir <rc...@gmail.com>.
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
<da...@cs.put.poznan.pl>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 <rc...@gmail.com> 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 <
> dawid.weiss@cs.put.poznan.pl>
> > wrote:
> >>
> >> Uwe -- could this be integrated in security manager's checkConnect?
> >>
> >> Dawid
> >>
> >> On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <erickerickson@gmail.com
> >
> >> 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 <rc...@gmail.com> 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
> >> >> <er...@gmail.com>
> >> >> 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 <rc...@gmail.com>
> 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: dev-unsubscribe@lucene.apache.org
> >> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
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 <rc...@gmail.com> 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 <da...@cs.put.poznan.pl>
> wrote:
>>
>> Uwe -- could this be integrated in security manager's checkConnect?
>>
>> Dawid
>>
>> On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <er...@gmail.com>
>> 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 <rc...@gmail.com> 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
>> >> <er...@gmail.com>
>> >> 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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Robert Muir <rc...@gmail.com>.
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 <da...@cs.put.poznan.pl>wrote:
> Uwe -- could this be integrated in security manager's checkConnect?
>
> Dawid
>
> On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <er...@gmail.com>
> 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 <rc...@gmail.com> 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 <erickerickson@gmail.com
> >
> >> 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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
Uwe -- could this be integrated in security manager's checkConnect?
Dawid
On Sat, Jun 8, 2013 at 3:55 PM, Erick Erickson <er...@gmail.com> 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 <rc...@gmail.com> 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 <er...@gmail.com>
>> 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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Erick Erickson <er...@gmail.com>.
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 <rc...@gmail.com> 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 <er...@gmail.com>
> 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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Robert Muir <rc...@gmail.com>.
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 <er...@gmail.com>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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: FYI: localhost vs 127.0.0.1 in networking-related tests
Posted by Erick Erickson <er...@gmail.com>.
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 <rc...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org