linkedin/sensei — comment on commit 2ca216ed21e0b982e3ba4a2c5fbc1f8ea6beb4cc
File:  line 0
By jhartman:

Hi Terence,

I'm the maintainer of norbert, the library that sensei uses for distribution. I'd prefer to move forward with this changeset, and to instead improve the way sensei uses norbert. Sensei doesn't take advantage of newer norbert features to do request customization and routing. By doing so, it bypasses a lot of norbert's infrastructure to protect itself and it's degrader. This is really, really bad. If it just fixes the way it uses norbert, it will receive this implementation for free. This has been a task on my plate for a long time, but I never got around to it when I was on cloud in SNA since it wasn't prioritized. The initial step was taking in January, when we migrated to the latest norbert release.

Norbert already has a class almost exactly like this. See https://github.com/linkedin-sna/norbert/blob/master/network/src/main/scala/com/linkedin/norbert/network/partitioned/loadbalancer/PartitionedConsistentHashedLoadBalancerFactory.scala. This class builds a consistent hash wheel per partition, unlike your approach. The store space required, however, is the same. It's numPartitions * numBuckets in both cases.

I also believe I see a problem with your approach. You're mapping all the rings onto a single ring. Usually, you look up a position in the ring and "roll" until you find a spot. What happens when a machine goes down? Now a different machine that can't handle the partition will be the next in the slot. So do you intend to iterate until you find the next one?

Let's work together to use norbert's infrastructure properly.