If using a hostname to connect with DefaultNodeLocator, results in different server lookup hashing over classic enyim

[odyth]

If you are using a hostname to connect to memcache such as myelasticcache.number.usw2.cache.amazonaws.com, this results in the host name being used to generate keys to lookup servers with. Classic enyim resolves the host name and then uses the IP address. Because of this difference, this version will choose different nodes for getting / setting memcache values. If you are using both dotnetcore and enyim in the same environment e.g. your main web servers run on windows in IIS and you do background work in AWS Lambda, this difference causes major problems.

In this version of IMemcachedNode.cs a System.Net.EndPoint is used while in the regular version of Enyim it is a System.Net.IPEndPoint.

What was the reason for not using an IPEndPoint like regular Enyim? Why was this change made? 6b78cf5

[cnblogs-dudu]

It will be fixed in 2.1.10.

[cnblogs-dudu]

2.1.10 was released.

[gustavocarpaneses]

I still have a problem after 2.1.10:

The problem was in DefaultNodeLocator class, on GenerateKeys method, at this line:

string address = node.EndPoint.ToString();

On Classic EnyimMemcached, EndPoint is an IPEndPoint class and address variable will be {IP}:{Port}. But on EnyimMemcachedCore, EndPoint is an EndPoint class and address variable will be {AddressFamily}/{IP}:{Port}. This behavior will generate a different hash table, and consequently different results for the same key.

Example:

Node1: 172.16.1.116:11211
Node2: 172.16.4.238:11211
Key: _agentxmppclustercontrol_tdt04_27846_clb

On EnyimMemcached the locator will choose 172.16.1.116:11211. And on EnyimMemcachedCore the locator will choose 172.16.4.238:11211.

I don't know if exists a better (and less impact) solution than replacing the string removing the AddressFamily (and the slash) info.