cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Robenalt <>
Subject Re: Is it possible to achieve "sticky" request routing?
Date Tue, 05 Apr 2016 19:47:54 GMT
Aside from Jon's "why" question, I would point out that this only really
works because you are running a 3 node cluster with RF=3. If your cluster
is going to grow, you can't guarantee that any one server would have all
records. I'd be pretty hesitant to put an invisible constraint like that on
a cluster unless you're pretty sure it'll only ever be 3 nodes.

On Tue, Apr 5, 2016 at 9:34 AM, Jonathan Haddad <> wrote:

> Why is this a requirement?  Honestly I don't know why you would do this.
> On Sat, Apr 2, 2016 at 8:06 PM Mukil Kesavan <>
> wrote:
>> Hello,
>> We currently have 3 Cassandra servers running in a single datacenter with
>> a replication factor of 3 for our keyspace. We also use the SimpleSnitch
>> wiith DynamicSnitching enabled by default. Our load balancing policy is
>> TokenAwareLoadBalancingPolicy with RoundRobinPolicy as the child. This
>> overall configuration results in our client requests spreading equally
>> across our 3 servers.
>> However, we have a new requirement where we need to restrict a client's
>> requests to a single server and only go to the other servers on failure of
>> the previous server. This particular use case does not have high request
>> traffic.
>> Looking at the documentation the options we have seem to be:
>> 1. Play with the snitching (e.g. place each server into its own DC or
>> Rack) to ensure that requests always go to one server and failover to the
>> others if required. I understand that this may also affect replica
>> placement and we may need to run nodetool repair. So this is not our most
>> preferred option.
>> 2. Write a new load balancing policy that also uses the HostStateListener
>> for tracking host up and down messages, that essentially accomplishes
>> "sticky" request routing with failover to other nodes.
>> Is option 2 the only clean way of accomplishing our requirement?
>> Thanks,
>> Micky

Steve Robenalt
Software Architect <>
(office/cell): 916-505-1785

HighWire Press, Inc.
425 Broadway St, Redwood City, CA 94063

Technology for Scholarly Communication

View raw message