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 wrote:
> Could and should the port selecting logic be pulled out into one common
> implementation used throughout the code base? I
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 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
wrote:
> Would it be feasible to reserve chosen ports befo
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 wrote:
> I agree that we should have defaulted everything to using ephemeral ports
> and forced clients to exp
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
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 ephe
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 port
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
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 wrote:
> If we just default to 0 then the OS will pick is a port in whatever range
> is e
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 wrote:
>
>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett wrote:
>>
>> Why
On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett 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
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 wrote:
>
> +1
>
> I think it's better not to have the possibility of a port collision for
> people using Geod
+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 wr
13 matches
Mail list logo
