[ 
https://issues.apache.org/jira/browse/CASSANDRA-12733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554310#comment-15554310
 ] 

Alex Petrov edited comment on CASSANDRA-12733 at 10/11/16 7:32 AM:
-------------------------------------------------------------------

LGTM code-wise. This might not solve the problem for prepares that are 
happening across the cluster, but in case there is a collision (extremely 
unlikely or even impossible), this may at least give a pointer.

I've re-triggered both dtest CI jobs as trunk one has 80+ failures and 3.x one 
failed.


was (Author: ifesdjeen):
LGTM code-wise. I've re-triggered both dtest CI jobs as trunk one has 80+ 
failures and 3.x one failed.

> Throw an exception if there is a prepared statement id hash conflict.
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-12733
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12733
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Jeremiah Jordan
>            Assignee: Jeremiah Jordan
>            Priority: Minor
>             Fix For: 3.x
>
>
> I seriously doubt there is any chance of actually getting two prepared 
> statement strings that have the same MD5.  But there should probably be 
> checks in QueryProcessor.getStoredPreparedStatement that the query string of 
> the statement being prepared matches the query string of the ID returned from 
> the cache when one already exists there.



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

Reply via email to