Hi Gary, What atomly has written is correct, but there is an alternative option, custom routers: http://doc.akka.io/docs/akka/2.3.6/scala/routing.html#Custom_Router
If you use a cluster routing you are free to implement your own logic. There is a reusable ConsistentHashingRoutingLogic class: http://doc.akka.io/api/akka/2.3.6/?_ga=1.125824842.1520294582.1409309043#akka.routing.ConsistentHashingRoutingLogic If nothing else, you can take the code of that class and create your own one switching the hashing logic to whatever you want -Endre On Mon, Sep 29, 2014 at 11:47 PM, atomly <[email protected]> wrote: > > On Mon, Sep 29, 2014 at 4:17 PM, Gary Malouf <[email protected]> > wrote: > >> Looking at the reference documentation, it appears it may use the same >> functionality. > > > I don't believe that is correct. Akka appears to use MurmurHash whereas > memcached is, as you said, based off of ketama. > > You can find a clean Java implementation of memcached's ketama hashing in > the Spy client: > > https://github.com/dustin/java-memcached-client/blob/master/src/main/java/net/spy/memcached/KetamaNodeLocator.java#L172 > > Akka's, on the other hand, is here: > > https://github.com/akka/akka/blob/v2.3.6/akka-actor/src/main/scala/akka/routing/ConsistentHash.scala#L111 > > https://github.com/akka/akka/blob/v2.3.6/akka-actor/src/main/scala/akka/routing/ConsistentHashing.scala#L153 > > As you see on the NodeLocator, you can easily pass in a new hashing > algorithm instead of its default-- I imagine it wouldn't be too much work > to use the same MurmurHash implementation that Akka is using. > > You also need to make sure, though, that the same thing is being hashed-- > the key, in memcached terms. It appears Akka has the notion of an envelope > that you can use to affect a message's hashing/routing, so this should be > possible. > > I have also, in the past, written a custom NodeLocator for the Spy > memcached client-- it allowed us to hash certain keys based on their prefix > and made all user keys use the username as a prefix, so that key "foo" for > user "user" would be "user:foo" but would only hash based off of the > prefix, aka the username, so that all keys for any given user would be > grouped on a server and would be able to be loaded with one multi-get, > cutting down our latency in a very high load environment-- and it is not > that difficult. If you have any questions, I may be able to help... > > :: atomly :: > > [ [email protected] : www.atomly.com : http://blog.atomly.com/ ... > [ atomiq records : new york city : +1.347.692.8661 ... > [ e-mail [email protected] for atomly info and updates ... > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
