Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 21 Jun 2016 21:25:58 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916909.1448876954000.15957.1466544358302@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: Tue, 21 Jun 2016 21:26:00 -0000


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

Tyler Hobbs commented on CASSANDRA-10786:
-----------------------------------------

bq. We (java driver team) discussed this and we agree with taking the appro=
ach we've previously taken, we can do a separate branch with this change, b=
uild a jar and include it with C* (in the lib/ directory as currently done)=
. We'll do some extra validation to make sure everything is good from the d=
river side. After a driver has been formally released with those changes, w=
e would want to update C* to use that.

That sounds good to me.

bq. What is the timeline of this change? Will it be in 3.8 or 3.10?

This might be included in 3.8, but...

bq. Will this be the only change in for protocol v5 or will some of the tic=
kets in CASSANDRA-9362 be included as well?

We probably want to wait for some of those other features before finalizing=
 the v5 protocol.  However, we can release with some of the v5 features imp=
lemented without actually allowing v5 connections to be made.  For testing,=
 we can use a special flag to allow v5 connections.  With that in mind, I d=
on't necessarily think we should make v5 whatever ends up in 3.8 -- we shou=
ld get in the features we really care about and finalize v5 in whatever C* =
release that happens to be.

[~slebresne] what do you think of the above? Is there anything in CASSANDRA=
-9362 that you would particularly like to get into the v5 protocol?

> 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, doc-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)