[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-10786: - Labels: LWT client-impacting doc-impacting protocolv5 (was: client-impacting doc-impacting protocolv5) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: LWT, client-impacting, doc-impacting, protocolv5 > Fix For: 4.0 > > > {color:red} > Warning for implementors: the spec has a typo, see CASSANDRA-13986 > {color} > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Michallat updated CASSANDRA-10786: -- Description: {color:red} Warning for implementors: the spec has a typo, see CASSANDRA-13986 {color} *_Initial description:_* This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. - *_Resolution (2017/02/13):_* The following changes were made to native protocol v5: - the PREPARED response includes {{result_metadata_id}}, a hash of the result set metadata. - every EXECUTE message must provide {{result_metadata_id}} in addition to the prepared statement id. If it doesn't match the current one on the server, it means the client is operating on a stale schema. - to notify the client, the server returns a ROWS response with a new {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated result metadata (this overrides the {{No_metadata}} flag, even if the client had requested it) - the client updates its copy of the result metadata before it decodes the results. So the scenario above would now look like: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and result set (b, c) that hashes to cde456 # column a gets added to the table, C* does not invalidate its cache entry, but only updates the result set to (a, b, c) which hashes to fff789 # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) and skip_metadata flag # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) # client updates its column specifications, and will send the next execute queries with (statementId=abc123, resultId=fff789) This works the same with multiple clients. was: *_Initial description:_* This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. - *_Resolution (2017/02/13):_* The following changes were made to native protocol v5: - the PREPARED response includes {{result_metadata_id}}, a hash of the result set metadata. - every EXECUTE message must provide {{result_metadata_id}} in addition to the prepared statement id. If it doesn't match the current one on the server, it means the client is operating on a
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10786: -- Fix Version/s: (was: 4.x) 4.0 > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.0 > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed to trunk with [922dbdb658b1693973926026b213153d05b4077c|https://github.com/apache/cassandra/commit/922dbdb658b1693973926026b213153d05b4077c] Big thanks to everyone for help! Follow-up blocker issue created: [CASSANDRA-13951] > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Status: Ready to Commit (was: Patch Available) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Status: Patch Available (was: Open) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-10786: --- Status: In Progress (was: Ready to Commit) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-10786: - Status: Patch Available (was: Open) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-10786: - Status: Ready to Commit (was: Patch Available) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-10786: - Status: Open (was: Ready to Commit) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anonymous updated CASSANDRA-10786: -- Status: Ready to Commit (was: Patch Available) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Status: Patch Available (was: Open) [~snazy] I've prepared a patch. It contains a new version of {{java-driver}} ({{3.4.0-SNAPSHOT}}), the pull request to the driver is [here|https://github.com/datastax/java-driver/pull/794]. |[trunk|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:10786-trunk-rebase]|[testall|http://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10786-trunk-rebase-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10786-trunk-rebase-dtest/]| In order to run driver tests (from the PR mentioned above) run: {code} mvn test -Pshort -Dtest=com.datastax.driver.core.PreparedStatementInvalidationTest -Dcassandra.version=4.0 -Dcassandra.directory=path_to_cassandra_with_10786 {code} > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Reviewer: Robert Stupp > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Reviewer: (was: Tyler Hobbs) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, protocolv5 > Fix For: 4.x > > > *_Initial description:_* > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. > - > *_Resolution (2017/02/13):_* > The following changes were made to native protocol v5: > - the PREPARED response includes {{result_metadata_id}}, a hash of the result > set metadata. > - every EXECUTE message must provide {{result_metadata_id}} in addition to > the prepared statement id. If it doesn't match the current one on the server, > it means the client is operating on a stale schema. > - to notify the client, the server returns a ROWS response with a new > {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated > result metadata (this overrides the {{No_metadata}} flag, even if the client > had requested it) > - the client updates its copy of the result metadata before it decodes the > results. > So the scenario above would now look like: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and > result set (b, c) that hashes to cde456 > # column a gets added to the table, C* does not invalidate its cache entry, > but only updates the result set to (a, b, c) which hashes to fff789 > # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) > and skip_metadata flag > # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, > metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) > # client updates its column specifications, and will send the next execute > queries with (statementId=abc123, resultId=fff789) > This works the same with multiple clients. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Michallat updated CASSANDRA-10786: -- Description: *_Initial description:_* This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. - *_Resolution (2017/02/13):_* The following changes were made to native protocol v5: - the PREPARED response includes {{result_metadata_id}}, a hash of the result set metadata. - every EXECUTE message must provide {{result_metadata_id}} in addition to the prepared statement id. If it doesn't match the current one on the server, it means the client is operating on a stale schema. - to notify the client, the server returns a ROWS response with a new {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated result metadata (this overrides the {{No_metadata}} flag, even if the client had requested it) - the client updates its copy of the result metadata before it decodes the results. So the scenario above would now look like: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and result set (b, c) that hashes to cde456 # column a gets added to the table, C* does not invalidate its cache entry, but only updates the result set to (a, b, c) which hashes to fff789 # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) and skip_metadata flag # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) # client updates its column specifications, and will send the next execute queries with (statementId=abc123, resultId=fff789) This works the same with multiple clients. was: *_Initial description:_* This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. - *_Resolution:_* The following changes were made to native protocol v5: - the PREPARED response includes {{result_metadata_id}}, a hash of the result set metadata. - every EXECUTE message must provide {{result_metadata_id}} in addition to the prepared statement id. If it doesn't match the current one on the server, it means the client is operating on a stale schema. - to notify the client, the server returns a ROWS response with a new {{Metadata_chang
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Michallat updated CASSANDRA-10786: -- Description: *_Initial description:_* This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. - *_Resolution:_* The following changes were made to native protocol v5: - the PREPARED response includes {{result_metadata_id}}, a hash of the result set metadata. - every EXECUTE message must provide {{result_metadata_id}} in addition to the prepared statement id. If it doesn't match the current one on the server, it means the client is operating on a stale schema. - to notify the client, the server returns a ROWS response with a new {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated result metadata (this overrides the {{No_metadata}} flag, even if the client had requested it) - the client updates its copy of the result metadata before it decodes the results. So the scenario above would now look like: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and result set (b, c) that hashes to cde456 # column a gets added to the table, C* does not invalidate its cache entry, but only updates the result set to (a, b, c) which hashes to fff789 # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) and skip_metadata flag # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c)) # client updates its column specifications, and will send the next execute queries with (statementId=abc123, resultId=fff789) This works the same with multiple clients. was: This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, pro
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-10786: Status: Open (was: Patch Available) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > 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 > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Issue Type: Sub-task (was: Bug) Parent: CASSANDRA-9362 > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Sub-task > 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 > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Status: Patch Available (was: Open) What I've done was simply re-preparing and having try/catch around. But I think you're right, it might be too error-prone to do it that way. It might be better to let users re-prepare the very first statement and let the rest be handled through the new {{Rows}}. The patch is located here. Test failure for {{UserTypesTest#testAlteringUserTypeNestedWithinNonFrozenMap}} even though looks related, was failing on trunk, the patch for it is submitted [here|https://issues.apache.org/jira/browse/CASSANDRA-12010]. The other tests seem unrelated and are failing on trunk, too. Please note that the patched binary for the driver was updated in tree, for test purposes. Test runs: |[trunk|https://github.com/ifesdjeen/cassandra/tree/10786-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10756-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10786-trunk-dtest/]| And patch for the driver is located [here|https://github.com/ifesdjeen/java-driver/tree/10786-v5]. > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > 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 > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Status: Open (was: Patch Available) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > 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 > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Labels: client-impacting doc-impacting protocolv5 (was: client-impacting protocolv5) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > 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 > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-10786: Labels: client-impacting protocolv5 (was: client-impacting) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > 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 > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-10786: Reviewer: Tyler Hobbs > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting > Fix For: 3.x > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Status: Patch Available (was: Open) |[trunk|https://github.com/ifesdjeen/cassandra/tree/10786-trunk] |[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10786-trunk-testall/] |[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10786-trunk-dtest/] | > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting > Fix For: 3.x > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10786: Labels: client-impacting (was: ) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting > Fix For: 3.x > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Michallat updated CASSANDRA-10786: -- Description: This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. For example: # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB both have a cache of the metadata (columns b and c) locally # column a gets added to the table, C* invalidates its cache entry # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares on the fly and updates its local metadata to (a, b, c) # prepared statement is now in C*’s cache again, with the same md5 abc123 # clientB sends an EXECUTE request for id abc123. Because the cache has been populated again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c) One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared. was: This is a follow-up to CASSANDRA-7910, which was about invalidating a prepared 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 will receive an UNPREPARED response, re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5 hasn't changed), and they will keep using their old metadata. One solution that was suggested is to include a hash of the result set metadata in the prepared statement id. The old id would become invalid, forcing all clients to reprepare. > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Olivier Michallat >Assignee: Alex Petrov >Priority: Minor > Fix For: 3.x > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. For example: > # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, > clientA and clientB both have a cache of the metadata (columns b and c) > locally > # column a gets added to the table, C* invalidates its cache entry > # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, > re-prepares on the fly and updates its local metadata to (a, b, c) > # prepared statement is now in C*’s cache again, with the same md5 abc123 > # clientB sends an EXECUTE request for id abc123. Because the cache has been > populated again, the query succeeds. But clientB still has not updated its > metadata, it’s still (b,c) > One solution that was suggested is to include a hash of the result set > metadata 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 > client already reprepared. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-10786: - Issue Type: Bug (was: Improvement) > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Olivier Michallat >Priority: Minor > Fix For: 3.x > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. > One solution that was suggested is to include a hash of the result set > metadata in the prepared statement id. The old id would become invalid, > forcing all clients to reprepare. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10786: -- Fix Version/s: (was: 3.2) 3.x > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Olivier Michallat >Priority: Minor > Fix For: 3.x > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. > One solution that was suggested is to include a hash of the result set > metadata in the prepared statement id. The old id would become invalid, > forcing all clients to reprepare. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-10786: Fix Version/s: 3.2 > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Olivier Michallat >Priority: Minor > Fix For: 3.2 > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. > One solution that was suggested is to include a hash of the result set > metadata in the prepared statement id. The old id would become invalid, > forcing all clients to reprepare. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-10786: Component/s: CQL > Include hash of result set metadata in prepared statement id > > > Key: CASSANDRA-10786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10786 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Olivier Michallat >Priority: Minor > Fix For: 3.2 > > > This is a follow-up to CASSANDRA-7910, which was about invalidating a > prepared 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 will > receive an UNPREPARED response, re-prepare, and update its local metadata. > But other clients might miss it entirely (the MD5 hasn't changed), and they > will keep using their old metadata. > One solution that was suggested is to include a hash of the result set > metadata in the prepared statement id. The old id would become invalid, > forcing all clients to reprepare. -- This message was sent by Atlassian JIRA (v6.3.4#6332)