I thought the deadline for comments was extended until today (27th), so I added a new comment on the RFC. I’m confused about the direction we are taking with this proposal.
- Aaron > On Mar 27, 2020, at 11:14 AM, Dan Smith <dsm...@pivotal.io> wrote: > > With this PR, it would be possible to identify servers running with the >> same ip and port, because now they will be identified by member id. But >> Bruce realized that it could be a problem if two servers are running in the >> same JVM, as they will share the same member id. It seems its very unlikely >> that people are doing it, but its not explicitly prohibited. >> > > What is going to happen if a user does set things up this way? The things I > can think of are: > > 1. When a connection to one of the cache server fails, the client will > close all of the connections to both. But this doesn't seem like a bad > outcome, since it's likely the whole server crashed anyway. > 2. Pings might not reach the correct server - but it looks like we have a > single ClientHealthMonitor for the server process anyway? So I think the > pings are getting to the right place. > > If there aren't any other negative outcomes, I think it's ok to proceed > with the current solution. But I'd also be ok going to ip+port+id. > > I also agree that this use case of a single pool connecting to multiple > cache servers in the same process doesn't make much sense. > > -Dan
