[
https://issues.apache.org/jira/browse/CASSANDRA-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893820#action_12893820
]
Gary Dusbabek commented on CASSANDRA-1335:
------------------------------------------
It wouldn't be that difficult to make the system_* methods optionally blocking
(throw a timeout exception after rpc_timeout_in_ms).
Is your concern that a server under load will not be able to respond to the
schema_agreement request and give a false indication that the update hasn't
promulgated? How long are you waiting before checking agreement? Maybe you
should just wait longer. At the very least, you should wait for
rpc_timeout_in_ms.
I kind of like the idea of applications handling this, or just letting the
writes/updates fail (as they should when a keyspace/cf doesn't exist, etc.).
> Add Consistency Level for Schema Creation Operations
> ----------------------------------------------------
>
> Key: CASSANDRA-1335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1335
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5.2
> Trunc
> Reporter: Arya Goudarzi
>
> Currently when applications create Keyspaces and CFs dynamically, user at
> application level has to make 2-3 calls to Cassandra to verify consistency of
> the schema as follows for example:
> 1. system_add_column_family
> 2. check_schema_agreement (will return a checksum of schema definitions and
> the nodes agreeing on them, user has to count the result to see if there is
> one checksum with all nodes meaning agreed or multiple checksums which means
> disagreed;)
> With clusters that have many application servers talking to them with high
> concurrency, it is possible for result from check_schema_agreement to be
> inconsistent in different nodes causing application misunderstanding of
> schema since application is no aware how the schema checksum is calculated.
> One solution that I've thought to add at the application level is to create
> locks using memcache on CF and KS creation operations so that many clients
> don't collide. However, I have to loop through check_schema_agreement and
> store the state and also do describe_keyspace, hence a 3rd call, since I am
> not sure how the checksum is calculated in order to verify I am not asking
> another client to create the same CF or KS. This potentially could fall into
> infinit loop if client calls fail and I have to bind to an application level
> timeout detection to I don't loop forever.
> I think it would highly make sense to have something like ConsistencyLevel
> added to schema creation operation to avoid users having to implement their
> locking and validation at their application level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
