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 <jbarr...@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 <aba...@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 <jbarr...@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 <dsm...@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 <jbarr...@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 <dsm...@pivotal.io> wrote: > >>>>>> > >>>>>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett <jbarr...@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 > >>>> > > >
