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 <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 > > >>>> > > > > > >
