proposing reduced default for "membership-port-range"

[Brian Rowe <br...@pivotal.io>]

Currently the default value for this parameter covers the default locator
and server port values.  As a result of this, when launching a locator and
then a server on the same system using gfsh, it's possible to see the
server fail because the locator has already bound the default server
socket.  We've actually seen a couple of test runs fail with this issue.

The proposed new range is 41000-61000, which, in addition to not
overlapping the other default port values, has the benefit of being a
subset of the linux ephemeral ports (for users who care about such
things).  Please let me know if there are any objections to this change.

Here's the current javadoc for this parameter:

Description: The allowed range of ports for use in forming an unique
membership identifier (UDP), for failure detection purposes (TCP) and to
listen on for peer connections (TCP). This range is given as two numbers
separated by a minus sign. Minimum 3 values in range are required to
successfully startup.
Default: 1024-65535

Re: proposing reduced default for "membership-port-range"

[Brian Rowe <br...@pivotal.io>]

It should be, but I don't believe it can be.  Some of the places that we
pass the membership range to are third party.

On Thu, Oct 11, 2018 at 11:54 AM, Helena Bales <hb...@pivotal.io> wrote:

> Could and should the port selecting logic be pulled out into one common
> implementation used throughout the code base? It seems like having a common
> implementation of this would make it a lot easier to solve this type of
> problem in the future.
>
> On Thu, Oct 11, 2018 at 11:27 AM Brian Rowe <br...@pivotal.io> wrote:
>
> > Galen, this was actually my first instinct.  Unfortunately this range is
> > passed into numerous places such as JGroups and BeanUtils, all of which
> > implement their own port selecting logic.
> >
> > On Thu, Oct 11, 2018 at 10:35 AM, Galen O'Sullivan <
> gosullivan@pivotal.io>
> > wrote:
> >
> > > Would it be feasible to reserve chosen ports before selecting ephemeral
> > > ports? I think this would resolve the collision issue described above.
> > >
> > > On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe <br...@pivotal.io> wrote:
> > >
> > > > I agree that we should have defaulted everything to using ephemeral
> > ports
> > > > and forced clients to explicitly assign ports and membership ranges
> if
> > > > needed (any of the reasons Anthony mentioned above).  However, I
> don't
> > > > think we can change the default assigned ports at this point, unless
> we
> > > > want to try to go through the effort of verifying that no customers
> are
> > > > relying on the default assignments (is that even something we can do
> > with
> > > > any confidence?).  The membership port range default, however, is
> > > something
> > > > we should be able to change, so long as we restrict it to a proper
> > subset
> > > > of the current default.  I think the best we can do right now is just
> > to
> > > > make it so the default membership port range doesn't conflict with
> the
> > > > default assigned ports.
> > > >
> > > > On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett <jb...@pivotal.io>
> > > wrote:
> > > >
> > > > > So in the Dockerfile you explicitly set the server to start on port
> > > > 40404,
> > > > > problem solved. In whatever environment where you need it on a
> > specific
> > > > > port you then assign that port. But for all the other cases where
> we
> > > > don’t
> > > > > need to know it, like most of the time, it should just pick
> something
> > > > > ephemeral and work.
> > > > >
> > > > >
> > > > > > On Oct 5, 2018, at 1:57 PM, Anthony Baker <ab...@pivotal.io>
> > wrote:
> > > > > >
> > > > > > I think there are a lot of dependencies when deploying geode that
> > > rely
> > > > > on well-known ports and port ranges (e.g. exporting ports from a
> > > > container,
> > > > > firewall rules, etc).  Changing the default server port from 40404
> to
> > > ??
> > > > > would break stuff.
> > > > > >
> > > > > > Here’s the rule from our own Dockerfile:
> > > > > >
> > > > > > # Default ports:
> > > > > > # RMI/JMX 1099
> > > > > > # REST 8080
> > > > > > # PULE 7070
> > > > > > # LOCATOR 10334
> > > > > > # CACHESERVER 40404
> > > > > > EXPOSE  8080 10334 40404 1099 7070
> > > > > >
> > > > > > Anthony
> > > > > >
> > > > > >
> > > > > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io>
> > > > wrote:
> > > > > >>
> > > > > >> But if all ports where ephemeral by default then no collisions
> > > right?
> > > > > Why have any port have a default to a single fixed value or
> > overlapping
> > > > > range of values. Since our opinionated use case is for clients to
> > > connect
> > > > > via locators then a known server port isn’t important.
> > > > > >>
> > > > > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io>
> > wrote:
> > > > > >>>
> > > > > >>> The problem is that the membership port is picked *first*. So
> it
> > > may
> > > > > pick
> > > > > >>> 40404. Then, when the cache server tries to use port 40404, it
> > > gets a
> > > > > >>> collision.
> > > > > >>>
> > > > > >>> -Dan
> > > > > >>>
> > > > > >>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <
> > > jbarrett@pivotal.io>
> > > > > wrote:
> > > > > >>>>
> > > > > >>>> If we just default to 0 then the OS will pick is a port in
> > > whatever
> > > > > range
> > > > > >>>> is ephemeral and free. We don’t have to do any work. No need
> to
> > > > > define a
> > > > > >>>> range and seek an open port.
> > > > > >>>>
> > > > > >>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io>
> > > wrote:
> > > > > >>>>>>
> > > > > >>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> > > > jbarrett@pivotal.io>
> > > > > >>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>> Why not change the default behavior to that of port 0,
> letting
> > > the
> > > > > OS
> > > > > >>>>>> select an open ephemeral port if the user doesn’t specify a
> > > > specific
> > > > > >>>> port?
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>> I think what we'd really like to do is change the cache
> server
> > > port
> > > > > to
> > > > > >>>>> something other than 40404. Maybe 0 (pick a port), or maybe
> > > > something
> > > > > >>>> less
> > > > > >>>>> than 32K.
> > > > > >>>>>
> > > > > >>>>> Unfortunately, on most linux distributions the ephemeral port
> > > range
> > > > > is
> > > > > >>>> 32K
> > > > > >>>>> -> 61K, which includes 40404, which I think is why Brian is
> > > > > proposing a
> > > > > >>>>> subset of that range.
> > > > > >>>>>
> > > > > >>>>> -Dan
> > > > > >>>>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: proposing reduced default for "membership-port-range"

[Helena Bales <hb...@pivotal.io>]

Could and should the port selecting logic be pulled out into one common
implementation used throughout the code base? It seems like having a common
implementation of this would make it a lot easier to solve this type of
problem in the future.

On Thu, Oct 11, 2018 at 11:27 AM Brian Rowe <br...@pivotal.io> wrote:

> Galen, this was actually my first instinct.  Unfortunately this range is
> passed into numerous places such as JGroups and BeanUtils, all of which
> implement their own port selecting logic.
>
> On Thu, Oct 11, 2018 at 10:35 AM, Galen O'Sullivan <go...@pivotal.io>
> wrote:
>
> > Would it be feasible to reserve chosen ports before selecting ephemeral
> > ports? I think this would resolve the collision issue described above.
> >
> > On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe <br...@pivotal.io> wrote:
> >
> > > I agree that we should have defaulted everything to using ephemeral
> ports
> > > and forced clients to explicitly assign ports and membership ranges if
> > > needed (any of the reasons Anthony mentioned above).  However, I don't
> > > think we can change the default assigned ports at this point, unless we
> > > want to try to go through the effort of verifying that no customers are
> > > relying on the default assignments (is that even something we can do
> with
> > > any confidence?).  The membership port range default, however, is
> > something
> > > we should be able to change, so long as we restrict it to a proper
> subset
> > > of the current default.  I think the best we can do right now is just
> to
> > > make it so the default membership port range doesn't conflict with the
> > > default assigned ports.
> > >
> > > On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >
> > > > So in the Dockerfile you explicitly set the server to start on port
> > > 40404,
> > > > problem solved. In whatever environment where you need it on a
> specific
> > > > port you then assign that port. But for all the other cases where we
> > > don’t
> > > > need to know it, like most of the time, it should just pick something
> > > > ephemeral and work.
> > > >
> > > >
> > > > > On Oct 5, 2018, at 1:57 PM, Anthony Baker <ab...@pivotal.io>
> wrote:
> > > > >
> > > > > I think there are a lot of dependencies when deploying geode that
> > rely
> > > > on well-known ports and port ranges (e.g. exporting ports from a
> > > container,
> > > > firewall rules, etc).  Changing the default server port from 40404 to
> > ??
> > > > would break stuff.
> > > > >
> > > > > Here’s the rule from our own Dockerfile:
> > > > >
> > > > > # Default ports:
> > > > > # RMI/JMX 1099
> > > > > # REST 8080
> > > > > # PULE 7070
> > > > > # LOCATOR 10334
> > > > > # CACHESERVER 40404
> > > > > EXPOSE  8080 10334 40404 1099 7070
> > > > >
> > > > > Anthony
> > > > >
> > > > >
> > > > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io>
> > > wrote:
> > > > >>
> > > > >> But if all ports where ephemeral by default then no collisions
> > right?
> > > > Why have any port have a default to a single fixed value or
> overlapping
> > > > range of values. Since our opinionated use case is for clients to
> > connect
> > > > via locators then a known server port isn’t important.
> > > > >>
> > > > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io>
> wrote:
> > > > >>>
> > > > >>> The problem is that the membership port is picked *first*. So it
> > may
> > > > pick
> > > > >>> 40404. Then, when the cache server tries to use port 40404, it
> > gets a
> > > > >>> collision.
> > > > >>>
> > > > >>> -Dan
> > > > >>>
> > > > >>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <
> > jbarrett@pivotal.io>
> > > > wrote:
> > > > >>>>
> > > > >>>> If we just default to 0 then the OS will pick is a port in
> > whatever
> > > > range
> > > > >>>> is ephemeral and free. We don’t have to do any work. No need to
> > > > define a
> > > > >>>> range and seek an open port.
> > > > >>>>
> > > > >>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io>
> > wrote:
> > > > >>>>>>
> > > > >>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> > > jbarrett@pivotal.io>
> > > > >>>> wrote:
> > > > >>>>>>
> > > > >>>>>> Why not change the default behavior to that of port 0, letting
> > the
> > > > OS
> > > > >>>>>> select an open ephemeral port if the user doesn’t specify a
> > > specific
> > > > >>>> port?
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> I think what we'd really like to do is change the cache server
> > port
> > > > to
> > > > >>>>> something other than 40404. Maybe 0 (pick a port), or maybe
> > > something
> > > > >>>> less
> > > > >>>>> than 32K.
> > > > >>>>>
> > > > >>>>> Unfortunately, on most linux distributions the ephemeral port
> > range
> > > > is
> > > > >>>> 32K
> > > > >>>>> -> 61K, which includes 40404, which I think is why Brian is
> > > > proposing a
> > > > >>>>> subset of that range.
> > > > >>>>>
> > > > >>>>> -Dan
> > > > >>>>
> > > > >
> > > >
> > >
> >
>

Re: proposing reduced default for "membership-port-range"

[Brian Rowe <br...@pivotal.io>]

Galen, this was actually my first instinct.  Unfortunately this range is
passed into numerous places such as JGroups and BeanUtils, all of which
implement their own port selecting logic.

On Thu, Oct 11, 2018 at 10:35 AM, Galen O'Sullivan <go...@pivotal.io>
wrote:

> Would it be feasible to reserve chosen ports before selecting ephemeral
> ports? I think this would resolve the collision issue described above.
>
> On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe <br...@pivotal.io> wrote:
>
> > I agree that we should have defaulted everything to using ephemeral ports
> > and forced clients to explicitly assign ports and membership ranges if
> > needed (any of the reasons Anthony mentioned above).  However, I don't
> > think we can change the default assigned ports at this point, unless we
> > want to try to go through the effort of verifying that no customers are
> > relying on the default assignments (is that even something we can do with
> > any confidence?).  The membership port range default, however, is
> something
> > we should be able to change, so long as we restrict it to a proper subset
> > of the current default.  I think the best we can do right now is just to
> > make it so the default membership port range doesn't conflict with the
> > default assigned ports.
> >
> > On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> > > So in the Dockerfile you explicitly set the server to start on port
> > 40404,
> > > problem solved. In whatever environment where you need it on a specific
> > > port you then assign that port. But for all the other cases where we
> > don’t
> > > need to know it, like most of the time, it should just pick something
> > > ephemeral and work.
> > >
> > >
> > > > On Oct 5, 2018, at 1:57 PM, Anthony Baker <ab...@pivotal.io> wrote:
> > > >
> > > > I think there are a lot of dependencies when deploying geode that
> rely
> > > on well-known ports and port ranges (e.g. exporting ports from a
> > container,
> > > firewall rules, etc).  Changing the default server port from 40404 to
> ??
> > > would break stuff.
> > > >
> > > > Here’s the rule from our own Dockerfile:
> > > >
> > > > # Default ports:
> > > > # RMI/JMX 1099
> > > > # REST 8080
> > > > # PULE 7070
> > > > # LOCATOR 10334
> > > > # CACHESERVER 40404
> > > > EXPOSE  8080 10334 40404 1099 7070
> > > >
> > > > Anthony
> > > >
> > > >
> > > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > > >>
> > > >> But if all ports where ephemeral by default then no collisions
> right?
> > > Why have any port have a default to a single fixed value or overlapping
> > > range of values. Since our opinionated use case is for clients to
> connect
> > > via locators then a known server port isn’t important.
> > > >>
> > > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io> wrote:
> > > >>>
> > > >>> The problem is that the membership port is picked *first*. So it
> may
> > > pick
> > > >>> 40404. Then, when the cache server tries to use port 40404, it
> gets a
> > > >>> collision.
> > > >>>
> > > >>> -Dan
> > > >>>
> > > >>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <
> jbarrett@pivotal.io>
> > > wrote:
> > > >>>>
> > > >>>> If we just default to 0 then the OS will pick is a port in
> whatever
> > > range
> > > >>>> is ephemeral and free. We don’t have to do any work. No need to
> > > define a
> > > >>>> range and seek an open port.
> > > >>>>
> > > >>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io>
> wrote:
> > > >>>>>>
> > > >>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> > jbarrett@pivotal.io>
> > > >>>> wrote:
> > > >>>>>>
> > > >>>>>> Why not change the default behavior to that of port 0, letting
> the
> > > OS
> > > >>>>>> select an open ephemeral port if the user doesn’t specify a
> > specific
> > > >>>> port?
> > > >>>>>>
> > > >>>>>
> > > >>>>> I think what we'd really like to do is change the cache server
> port
> > > to
> > > >>>>> something other than 40404. Maybe 0 (pick a port), or maybe
> > something
> > > >>>> less
> > > >>>>> than 32K.
> > > >>>>>
> > > >>>>> Unfortunately, on most linux distributions the ephemeral port
> range
> > > is
> > > >>>> 32K
> > > >>>>> -> 61K, which includes 40404, which I think is why Brian is
> > > proposing a
> > > >>>>> subset of that range.
> > > >>>>>
> > > >>>>> -Dan
> > > >>>>
> > > >
> > >
> >
>

Re: proposing reduced default for "membership-port-range"

[Galen O'Sullivan <go...@pivotal.io>]

Would it be feasible to reserve chosen ports before selecting ephemeral
ports? I think this would resolve the collision issue described above.

On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe <br...@pivotal.io> wrote:

> I agree that we should have defaulted everything to using ephemeral ports
> and forced clients to explicitly assign ports and membership ranges if
> needed (any of the reasons Anthony mentioned above).  However, I don't
> think we can change the default assigned ports at this point, unless we
> want to try to go through the effort of verifying that no customers are
> relying on the default assignments (is that even something we can do with
> any confidence?).  The membership port range default, however, is something
> we should be able to change, so long as we restrict it to a proper subset
> of the current default.  I think the best we can do right now is just to
> make it so the default membership port range doesn't conflict with the
> default assigned ports.
>
> On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> > So in the Dockerfile you explicitly set the server to start on port
> 40404,
> > problem solved. In whatever environment where you need it on a specific
> > port you then assign that port. But for all the other cases where we
> don’t
> > need to know it, like most of the time, it should just pick something
> > ephemeral and work.
> >
> >
> > > On Oct 5, 2018, at 1:57 PM, Anthony Baker <ab...@pivotal.io> wrote:
> > >
> > > I think there are a lot of dependencies when deploying geode that rely
> > on well-known ports and port ranges (e.g. exporting ports from a
> container,
> > firewall rules, etc).  Changing the default server port from 40404 to ??
> > would break stuff.
> > >
> > > Here’s the rule from our own Dockerfile:
> > >
> > > # Default ports:
> > > # RMI/JMX 1099
> > > # REST 8080
> > > # PULE 7070
> > > # LOCATOR 10334
> > > # CACHESERVER 40404
> > > EXPOSE  8080 10334 40404 1099 7070
> > >
> > > Anthony
> > >
> > >
> > >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >>
> > >> But if all ports where ephemeral by default then no collisions right?
> > Why have any port have a default to a single fixed value or overlapping
> > range of values. Since our opinionated use case is for clients to connect
> > via locators then a known server port isn’t important.
> > >>
> > >>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io> wrote:
> > >>>
> > >>> The problem is that the membership port is picked *first*. So it may
> > pick
> > >>> 40404. Then, when the cache server tries to use port 40404, it gets a
> > >>> collision.
> > >>>
> > >>> -Dan
> > >>>
> > >>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >>>>
> > >>>> If we just default to 0 then the OS will pick is a port in whatever
> > range
> > >>>> is ephemeral and free. We don’t have to do any work. No need to
> > define a
> > >>>> range and seek an open port.
> > >>>>
> > >>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
> > >>>>>>
> > >>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <
> jbarrett@pivotal.io>
> > >>>> wrote:
> > >>>>>>
> > >>>>>> Why not change the default behavior to that of port 0, letting the
> > OS
> > >>>>>> select an open ephemeral port if the user doesn’t specify a
> specific
> > >>>> port?
> > >>>>>>
> > >>>>>
> > >>>>> I think what we'd really like to do is change the cache server port
> > to
> > >>>>> something other than 40404. Maybe 0 (pick a port), or maybe
> something
> > >>>> less
> > >>>>> than 32K.
> > >>>>>
> > >>>>> Unfortunately, on most linux distributions the ephemeral port range
> > is
> > >>>> 32K
> > >>>>> -> 61K, which includes 40404, which I think is why Brian is
> > proposing a
> > >>>>> subset of that range.
> > >>>>>
> > >>>>> -Dan
> > >>>>
> > >
> >
>

Re: proposing reduced default for "membership-port-range"

[Brian Rowe <br...@pivotal.io>]

I agree that we should have defaulted everything to using ephemeral ports
and forced clients to explicitly assign ports and membership ranges if
needed (any of the reasons Anthony mentioned above).  However, I don't
think we can change the default assigned ports at this point, unless we
want to try to go through the effort of verifying that no customers are
relying on the default assignments (is that even something we can do with
any confidence?).  The membership port range default, however, is something
we should be able to change, so long as we restrict it to a proper subset
of the current default.  I think the best we can do right now is just to
make it so the default membership port range doesn't conflict with the
default assigned ports.

On Fri, Oct 5, 2018 at 3:42 PM, Jacob Barrett <jb...@pivotal.io> wrote:

> So in the Dockerfile you explicitly set the server to start on port 40404,
> problem solved. In whatever environment where you need it on a specific
> port you then assign that port. But for all the other cases where we don’t
> need to know it, like most of the time, it should just pick something
> ephemeral and work.
>
>
> > On Oct 5, 2018, at 1:57 PM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > I think there are a lot of dependencies when deploying geode that rely
> on well-known ports and port ranges (e.g. exporting ports from a container,
> firewall rules, etc).  Changing the default server port from 40404 to ??
> would break stuff.
> >
> > Here’s the rule from our own Dockerfile:
> >
> > # Default ports:
> > # RMI/JMX 1099
> > # REST 8080
> > # PULE 7070
> > # LOCATOR 10334
> > # CACHESERVER 40404
> > EXPOSE  8080 10334 40404 1099 7070
> >
> > Anthony
> >
> >
> >> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >>
> >> But if all ports where ephemeral by default then no collisions right?
> Why have any port have a default to a single fixed value or overlapping
> range of values. Since our opinionated use case is for clients to connect
> via locators then a known server port isn’t important.
> >>
> >>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io> wrote:
> >>>
> >>> The problem is that the membership port is picked *first*. So it may
> pick
> >>> 40404. Then, when the cache server tries to use port 40404, it gets a
> >>> collision.
> >>>
> >>> -Dan
> >>>
> >>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >>>>
> >>>> If we just default to 0 then the OS will pick is a port in whatever
> range
> >>>> is ephemeral and free. We don’t have to do any work. No need to
> define a
> >>>> range and seek an open port.
> >>>>
> >>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
> >>>>>>
> >>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io>
> >>>> wrote:
> >>>>>>
> >>>>>> Why not change the default behavior to that of port 0, letting the
> OS
> >>>>>> select an open ephemeral port if the user doesn’t specify a specific
> >>>> port?
> >>>>>>
> >>>>>
> >>>>> I think what we'd really like to do is change the cache server port
> to
> >>>>> something other than 40404. Maybe 0 (pick a port), or maybe something
> >>>> less
> >>>>> than 32K.
> >>>>>
> >>>>> Unfortunately, on most linux distributions the ephemeral port range
> is
> >>>> 32K
> >>>>> -> 61K, which includes 40404, which I think is why Brian is
> proposing a
> >>>>> subset of that range.
> >>>>>
> >>>>> -Dan
> >>>>
> >
>

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett <jb...@pivotal.io>]

So in the Dockerfile you explicitly set the server to start on port 40404, problem solved. In whatever environment where you need it on a specific port you then assign that port. But for all the other cases where we don’t need to know it, like most of the time, it should just pick something ephemeral and work.


> On Oct 5, 2018, at 1:57 PM, Anthony Baker <ab...@pivotal.io> wrote:
> 
> I think there are a lot of dependencies when deploying geode that rely on well-known ports and port ranges (e.g. exporting ports from a container, firewall rules, etc).  Changing the default server port from 40404 to ?? would break stuff.
> 
> Here’s the rule from our own Dockerfile:
> 
> # Default ports:
> # RMI/JMX 1099
> # REST 8080
> # PULE 7070
> # LOCATOR 10334
> # CACHESERVER 40404
> EXPOSE  8080 10334 40404 1099 7070
> 
> Anthony
> 
> 
>> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>> 
>> But if all ports where ephemeral by default then no collisions right? Why have any port have a default to a single fixed value or overlapping range of values. Since our opinionated use case is for clients to connect via locators then a known server port isn’t important. 
>> 
>>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io> wrote:
>>> 
>>> The problem is that the membership port is picked *first*. So it may pick
>>> 40404. Then, when the cache server tries to use port 40404, it gets a
>>> collision.
>>> 
>>> -Dan
>>> 
>>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <jb...@pivotal.io> wrote:
>>>> 
>>>> If we just default to 0 then the OS will pick is a port in whatever range
>>>> is ephemeral and free. We don’t have to do any work. No need to define a
>>>> range and seek an open port.
>>>> 
>>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>> 
>>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io>
>>>> wrote:
>>>>>> 
>>>>>> Why not change the default behavior to that of port 0, letting the OS
>>>>>> select an open ephemeral port if the user doesn’t specify a specific
>>>> port?
>>>>>> 
>>>>> 
>>>>> I think what we'd really like to do is change the cache server port to
>>>>> something other than 40404. Maybe 0 (pick a port), or maybe something
>>>> less
>>>>> than 32K.
>>>>> 
>>>>> Unfortunately, on most linux distributions the ephemeral port range is
>>>> 32K
>>>>> -> 61K, which includes 40404, which I think is why Brian is proposing a
>>>>> subset of that range.
>>>>> 
>>>>> -Dan
>>>> 
> 

Re: proposing reduced default for "membership-port-range"

[Anthony Baker <ab...@pivotal.io>]

I think there are a lot of dependencies when deploying geode that rely on well-known ports and port ranges (e.g. exporting ports from a container, firewall rules, etc).  Changing the default server port from 40404 to ?? would break stuff.

Here’s the rule from our own Dockerfile:

# Default ports:
# RMI/JMX 1099
# REST 8080
# PULE 7070
# LOCATOR 10334
# CACHESERVER 40404
EXPOSE  8080 10334 40404 1099 7070

Anthony


> On Oct 5, 2018, at 1:45 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> 
> But if all ports where ephemeral by default then no collisions right? Why have any port have a default to a single fixed value or overlapping range of values. Since our opinionated use case is for clients to connect via locators then a known server port isn’t important. 
> 
>> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io> wrote:
>> 
>> The problem is that the membership port is picked *first*. So it may pick
>> 40404. Then, when the cache server tries to use port 40404, it gets a
>> collision.
>> 
>> -Dan
>> 
>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <jb...@pivotal.io> wrote:
>>> 
>>> If we just default to 0 then the OS will pick is a port in whatever range
>>> is ephemeral and free. We don’t have to do any work. No need to define a
>>> range and seek an open port.
>>> 
>>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
>>>>> 
>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io>
>>> wrote:
>>>>> 
>>>>> Why not change the default behavior to that of port 0, letting the OS
>>>>> select an open ephemeral port if the user doesn’t specify a specific
>>> port?
>>>>> 
>>>> 
>>>> I think what we'd really like to do is change the cache server port to
>>>> something other than 40404. Maybe 0 (pick a port), or maybe something
>>> less
>>>> than 32K.
>>>> 
>>>> Unfortunately, on most linux distributions the ephemeral port range is
>>> 32K
>>>> -> 61K, which includes 40404, which I think is why Brian is proposing a
>>>> subset of that range.
>>>> 
>>>> -Dan
>>> 

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett <jb...@pivotal.io>]

But if all ports where ephemeral by default then no collisions right? Why have any port have a default to a single fixed value or overlapping range of values. Since our opinionated use case is for clients to connect via locators then a known server port isn’t important. 

> On Oct 5, 2018, at 10:55 AM, Dan Smith <ds...@pivotal.io> wrote:
> 
> The problem is that the membership port is picked *first*. So it may pick
> 40404. Then, when the cache server tries to use port 40404, it gets a
> collision.
> 
> -Dan
> 
>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <jb...@pivotal.io> wrote:
>> 
>> If we just default to 0 then the OS will pick is a port in whatever range
>> is ephemeral and free. We don’t have to do any work. No need to define a
>> range and seek an open port.
>> 
>>>> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
>>>> 
>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>>>> 
>>>> Why not change the default behavior to that of port 0, letting the OS
>>>> select an open ephemeral port if the user doesn’t specify a specific
>> port?
>>>> 
>>> 
>>> I think what we'd really like to do is change the cache server port to
>>> something other than 40404. Maybe 0 (pick a port), or maybe something
>> less
>>> than 32K.
>>> 
>>> Unfortunately, on most linux distributions the ephemeral port range is
>> 32K
>>> -> 61K, which includes 40404, which I think is why Brian is proposing a
>>> subset of that range.
>>> 
>>> -Dan
>> 

Re: proposing reduced default for "membership-port-range"

[Dan Smith <ds...@pivotal.io>]

The problem is that the membership port is picked *first*. So it may pick
40404. Then, when the cache server tries to use port 40404, it gets a
collision.

-Dan

On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett <jb...@pivotal.io> wrote:

> If we just default to 0 then the OS will pick is a port in whatever range
> is ephemeral and free. We don’t have to do any work. No need to define a
> range and seek an open port.
>
> > On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
> >
> >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io>
> wrote:
> >>
> >> Why not change the default behavior to that of port 0, letting the OS
> >> select an open ephemeral port if the user doesn’t specify a specific
> port?
> >>
> >
> > I think what we'd really like to do is change the cache server port to
> > something other than 40404. Maybe 0 (pick a port), or maybe something
> less
> > than 32K.
> >
> > Unfortunately, on most linux distributions the ephemeral port range is
> 32K
> > -> 61K, which includes 40404, which I think is why Brian is proposing a
> > subset of that range.
> >
> > -Dan
>

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett <jb...@pivotal.io>]

If we just default to 0 then the OS will pick is a port in whatever range is ephemeral and free. We don’t have to do any work. No need to define a range and seek an open port.

> On Oct 5, 2018, at 10:40 AM, Dan Smith <ds...@pivotal.io> wrote:
> 
>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io> wrote:
>> 
>> Why not change the default behavior to that of port 0, letting the OS
>> select an open ephemeral port if the user doesn’t specify a specific port?
>> 
> 
> I think what we'd really like to do is change the cache server port to
> something other than 40404. Maybe 0 (pick a port), or maybe something less
> than 32K.
> 
> Unfortunately, on most linux distributions the ephemeral port range is 32K
> -> 61K, which includes 40404, which I think is why Brian is proposing a
> subset of that range.
> 
> -Dan

Re: proposing reduced default for "membership-port-range"

[Dan Smith <ds...@pivotal.io>]

On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jb...@pivotal.io> wrote:

> Why not change the default behavior to that of port 0, letting the OS
> select an open ephemeral port if the user doesn’t specify a specific port?
>

I think what we'd really like to do is change the cache server port to
something other than 40404. Maybe 0 (pick a port), or maybe something less
than 32K.

Unfortunately, on most linux distributions the ephemeral port range is 32K
-> 61K, which includes 40404, which I think is why Brian is proposing a
subset of that range.

-Dan

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett <jb...@pivotal.io>]

Why not change the default behavior to that of port 0, letting the OS select an open ephemeral port if the user doesn’t specify a specific port?

> On Oct 5, 2018, at 9:02 AM, Dan Smith <ds...@pivotal.io> wrote:
> 
> +1
> 
> I think it's better not to have the possibility of a port collision for
> people using Geode's default settings. Especially if you are using
> automation to start and restart geode members, having a member fail to come
> up randomly is problematic.
> 
> -Dan
> 
>> On Thu, Oct 4, 2018 at 4:06 PM Brian Rowe <br...@pivotal.io> wrote:
>> 
>> Currently the default value for this parameter covers the default locator
>> and server port values.  As a result of this, when launching a locator and
>> then a server on the same system using gfsh, it's possible to see the
>> server fail because the locator has already bound the default server
>> socket.  We've actually seen a couple of test runs fail with this issue.
>> 
>> The proposed new range is 41000-61000, which, in addition to not
>> overlapping the other default port values, has the benefit of being a
>> subset of the linux ephemeral ports (for users who care about such
>> things).  Please let me know if there are any objections to this change.
>> 
>> Here's the current javadoc for this parameter:
>> 
>> Description: The allowed range of ports for use in forming an unique
>> membership identifier (UDP), for failure detection purposes (TCP) and to
>> listen on for peer connections (TCP). This range is given as two numbers
>> separated by a minus sign. Minimum 3 values in range are required to
>> successfully startup.
>> Default: 1024-65535
>> 

Re: proposing reduced default for "membership-port-range"

[Dan Smith <ds...@pivotal.io>]

+1

I think it's better not to have the possibility of a port collision for
people using Geode's default settings. Especially if you are using
automation to start and restart geode members, having a member fail to come
up randomly is problematic.

-Dan

On Thu, Oct 4, 2018 at 4:06 PM Brian Rowe <br...@pivotal.io> wrote:

> Currently the default value for this parameter covers the default locator
> and server port values.  As a result of this, when launching a locator and
> then a server on the same system using gfsh, it's possible to see the
> server fail because the locator has already bound the default server
> socket.  We've actually seen a couple of test runs fail with this issue.
>
> The proposed new range is 41000-61000, which, in addition to not
> overlapping the other default port values, has the benefit of being a
> subset of the linux ephemeral ports (for users who care about such
> things).  Please let me know if there are any objections to this change.
>
> Here's the current javadoc for this parameter:
>
> Description: The allowed range of ports for use in forming an unique
> membership identifier (UDP), for failure detection purposes (TCP) and to
> listen on for peer connections (TCP). This range is given as two numbers
> separated by a minus sign. Minimum 3 values in range are required to
> successfully startup.
> Default: 1024-65535
>