Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 19 May 2016 15:20:12 +0000 (UTC)
From: "Robert Stupp (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916909.1448876954000.236899.1463671212989@Atlassian.JIRA>
In-Reply-To: <JIRA.12916909.1448876954000@Atlassian.JIRA>
References: <JIRA.12916909.1448876954000@Atlassian.JIRA> <JIRA.12916909.1448876954569@arcas>
Subject: [jira] [Commented] (CASSANDRA-10786) Include hash of result set
 metadata in prepared statement id
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 19 May 2016 15:20:15 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15291273#comment-15291273 ]=20

Robert Stupp commented on CASSANDRA-10786:
------------------------------------------

Well, leaving the {{id}} (which is the {{MD5Digest}} for the pstmt) as is a=
llows backwards compatibility.
The purpose of a _fingerprint_ is to provide a hash over {{ResultSet.Result=
Metadata}} - something like a _prepared statement version_.

Imagine that a (reasonable) amount of time can elapse until all cluster nod=
es have processed the schema change. Nodes can be down for whatever reason =
and get the schema change late. Some nodes can be unreachable for other nod=
es but still be available for clients. (Network partitions occur when you d=
on't need them.)
Additionally, a client probably talks to all nodes "simultaneously" and the=
refore gets different results from nodes that have processed the schema cha=
nge and those that did not have processed it. Different results means: some=
 nodes will say: "i don't know that pstmt ID - please re-prepare" while oth=
ers respond as expected.
We should not make such situations worse (by causing a _prepare storm_) tha=
n it already is (schema disagreement).

For example, say you have an application that runs 100,000 queries per seco=
nd for a prepared statement.
At time=3D0, an {{ALTER TABLE foo ADD bar text}} is run. The schema migrati=
on takes for example 500ms (just a random number) until all nodes have "swi=
tched" their schema. This means that 50,000 queries may hit a node that has=
 the new schema and re-prepare but hit another node during the next request=
 that does not have the new schema.

Also, the information a driver gets via the _control connection_ is not "ju=
st in time" - unlucky driver instances may get the schema change notificati=
on via the control connections quite late.

I'm not a fan of changing the way we compute the pstmt {{id}} as we're plea=
sed between versions (either C* releases or protocol versions) for the same=
 reasons. I agree that we should probably not specify the algorithm to comp=
ute such IDs into the native protocol specification - but we should keep th=
e algorithm to compute these IDs consistent.


> Include hash of result set metadata in prepared statement id
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-10786
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1078=
6
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>            Reporter: Olivier Michallat
>            Assignee: Alex Petrov
>            Priority: Minor
>              Labels: client-impacting, protocolv5
>             Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a pre=
pared statement when the table is altered, to force clients to update their=
 local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host=
. The first client to execute the query after the cache was invalidated wil=
l receive an UNPREPARED response, re-prepare, and update its local metadata=
. But other clients might miss it entirely (the MD5 hasn't changed), and th=
ey will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, cl=
ientA and clientB both have a cache of the metadata (columns b and c) local=
ly
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED respon=
se, re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*=E2=80=99s cache again, with the same md=
5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has b=
een populated again, the query succeeds. But clientB still has not updated =
its metadata, it=E2=80=99s still (b,c)
> One solution that was suggested is to include a hash of the result set me=
tadata in the md5. This way the md5 would change at step 3, and any client =
using the old md5 would get an UNPREPARED, regardless of whether another cl=
ient already reprepared.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)