[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evolving the client protocol

The main point is that we decided to take a strategic decision to invest in
the client
side. We always wanted to get to the state but for natural reasons, it took
us a while.
The client side changes aren't just about a small feature here and there or
stop at
thread per core. Think about the changes that will come in a 3-5 year scope.

Avi had a great idea about changing the underline TCP to UDP. It removes
blocking, removes limitations of number of sockets and since clients
restrasmit on timeouts,
it will improve performance a lot.
Another change is in the CDC domain.

Some other idea that comes to my mind is to use IDL and automatic generate
to different languages, to improve reuse an d standardization Scylla
generated its internal RPC code from an IDL and modern implementations
should take
this path, especially with polyglot of languages. Believe me, it sounds
more and more compeling
to me as an easier path.

On Tue, Apr 24, 2018 at 9:26 AM, Avi Kivity <avi@xxxxxxxxxxxx> wrote:

> On 2018-04-24 04:18, Nate McCall wrote:
>> Folks,
>> Before this goes much further, let's take a step back for a second.
>> I am hearing the following: Folks are fine with CASSANDRA-14311 and
>> CASSANDRA-2848 *BUT* they don't make much sense from the project's
>> perspective without a reference implementation. I think the shard
>> concept is too abstract for the project right now, so we should
>> probably set that one aside.
>> Dor and Avi, I appreciate you both engaging directly on this. Where
>> can we find common ground on this?
> I started with three options:
> 1. Scylla (or other protocol implementers) contribute spec changes, and
> each implementer implements them on their own
> This was rejected.
> 2. Scylla defines and implements spec changes on its own, and when
> Cassandra implements similar changes, it will retroactively apply the
> Scylla change if it makes technical sense
> IOW, no gratuitous divergence, but no hard commitment either.
> I received no feedback on this.
> 3. No cooperation.
> This is the fall-back option which I would like to avoid if possible. It's
> main advantage is that it avoids long email threads and flamewars.
> There was also a suggestion made in this thread:
> 4. Scylla defines spec changes and also implements them for Cassandra
> That works for some changes but not all (for example, thread-per-core
> awareness, or changes that require significant effort). I would like to
> find a way that works for all of the changes that we want to make.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx