Multi get, pluggable hashing and some code cleanup (#1)

[blackmad]

This change implements multi-get, pluggable hashing and some (but not complete) code cleanup

pluggable hashing

• removes the failover options which would be hard to make work with pluggable hashing (if this is important to keep, I will figure out a way to add it back)
• implemented with the idea in mind of being able to use https://www.npmjs.com/package/hashring
• lots of tests added!

code cleanup

• move to tap v14 so tap.only works
• introduce a constants file, change most (but not all) magic numbers in memjs to use named constants
• start using "server" in many places rather than "serv"

I'd really like to move the eslint version forward so we can use const, let, =>, and array destructuring, but that seemed like it would be better suited to a separate PR

[saschat]

Hey @blackmad, thanks so much for all the work.

I have only looked at the pluggable hash function so far.

I don't think removing failover is a good idea for a couple of reasons.

• Without failover, you will be dogpiling servers whenever there is an issue... and in the cloud, there is always an issue eventually.
• For MemCachier caches, servers have a consistent view of the cache, so failovers are highly desirable since you will get the same answer from any server.

The good thing is that I don't think it is hard to keep failover at all. For the default function, you can just leave the "use next server" failover. Personally, I would also recommend the same failover for hashring as it is common practice. Btw. feel free to add the hashring function to choose a server to memjs in a future PR as well. I think @alevy has a TODO about adding one in the code anyway. The good thing about having both in memjs is that you can reuse the "use next server" failover.

[blackmad]

Thanks for the review! I originally had a version with hashring but noticed that the project had zero external dependencies so thought you might want to keep it that way, rewriting it to be pluggable ended up with cleaner code so I'm glad I did it, but awesome can add back in hashring in the future. re: failover, sounds like a simple change - I'll try to get in back in today.

…

On Mon, Mar 29, 2021 at 4:51 AM Sascha ***@***.***> wrote: Hey @blackmad <https://github.com/blackmad>, thanks so much for all the work. I have only looked at the pluggable hash function so far. I don't think removing failover is a good idea for a couple of reasons. - Without failover, you will be dogpiling servers whenever there is an issue... and in the cloud, there is always an issue eventually. - For MemCachier caches, servers have a consistent view of the cache, so failovers are highly desirable since you will get the same answer from any server. The good thing is that I don't think it is hard to keep failover at all. For the default function, you can just leave the "use next server" failover. Personally, I would also recommend the same failover for hashring as it is common practice. Btw. feel free to add the hashring function to choose a server to memjs in a future PR as well. I think @alevy <https://github.com/alevy> has a TODO about adding one in the code anyway. The good thing about having both in memjs is that you can reuse the "use next server" failover. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMZMBP3J2QQUWYDXPW2WDTGBETNANCNFSM4Z3LJ37Q> .

-- *David Blackman* creative technologist & wandering help me find my purpose <http://purpose.blackmad.com>

[tarwin]

Is the pluggable Hash going to be rolled into the main branch anytime soon? I'd love to be able to use this but need to write our own Hash support at the moment (horrible old PHP memcache compatible CRC32 hash urgh).

[saschat]

@blackmad any update? Have you thought about the 3 options above?