Hi Dan, I have realized that after this change, if you want to do a quick test in your laptop, it will be not possible to run two servers properly. There could be different scenarios you could not test. For example, you could not test what happens when a server is restarted, as both will be considered down.
So I think it would be better to use ip+port+id, it will have less impacts. BR/ Alberto B. ________________________________ De: Dan Smith <dsm...@pivotal.io> Enviado: viernes, 27 de marzo de 2020 19:14 Para: dev@geode.apache.org <dev@geode.apache.org> Asunto: Re: WAN replication issue in cloud native environments 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
