[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333114#comment-14333114
]
Robert Stupp edited comment on CASSANDRA-8831 at 2/23/15 10:14 AM:
-------------------------------------------------------------------
bq. {{use_keyspace_name}} vs. {{keyspace_name}}
For 2.1 the {{USE}} keyspace might not have any effect. But for 3.0 (UDFs) it
has. Additionally the {{prepared_id}} is calculated upon the current keyspace
and the statement.
Your other comments make sense - so I'll adopt them.
bq. writing them all every minute
It just synchronizes against the table every minute - so it's basically more a
_delayed/async write_. But you're right, only the first prepare would really
hit the (mem)table, meaning that the actual write is cheap - so I'll remove the
scheduled thing.
Attached v2 of the patch incorporates the changes.
bq. security concerns
We could add a configuration field to turn this feature on and off. WDYT?
was (Author: snazy):
bq. {{use_keyspace_name}} vs. {{keyspace_name}}
For 2.1 the {{USE}}d keyspace might not have any effect. But for 3.0 (UDFs) it
has. Additionally the {{prepared_id}} is calculated upon the current keyspace
and the statement.
Your other comments make sense - so I'll adopt them.
bq. writing them all every minute
It just synchronizes against the table every minute - so it's basically more a
_delayed/async write_. But you're right, only the first prepare would really
hit the (mem)table, meaning that the actual write is cheap - so I'll remove the
scheduled thing.
Attached v2 of the patch incorporates the changes.
bq. security concerns
We could add a configuration field to turn this feature on and off. WDYT?
> Create a system table to expose prepared statements
> ---------------------------------------------------
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Robert Stupp
> Attachments: 8831-v1.txt, 8831-v2.txt
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
> keyspace_name text,
> table_name text,
> prepared_id blob,
> query_string text,
> PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
