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

Tyler Hobbs commented on CASSANDRA-11920:
-----------------------------------------

bq. I feel validation should go into TableParams validate() method

Yes, that's the correct place for this.

bq. BloomCalculations class is having default access modifier, so not 
accessible from TableParams

Feel free to make classes, methods, or fields public as needed to support this.

> bloom_filter_fp_chance needs to be validated up front
> -----------------------------------------------------
>
>                 Key: CASSANDRA-11920
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11920
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Lifecycle, Local Write-Read Paths
>            Reporter: ADARSH KUMAR
>              Labels: lhf
>
> Hi,
> I was doing some bench-marking on bloom_filter_fp_chance values. Everything 
> worked fine for values .01(default for STCS), .001, .0001. But when I set 
> bloom_filter_fp_chance = .00001 i observed following behaviour:
> 1). Reads and writes looked normal from cqlsh.
> 2). SSttables are never created.
> 3). It just creates two files (*-Data.db and *-index.db) of size 0kb.
> 4). nodetool flush does not work and produce following exception:
> java.lang.UnsupportedOperationException: Unable to satisfy 1.0E-5 with 20 
> buckets per element
>         at 
> org.apache.cassandra.utils.BloomCalculations.computeBloomSpec(BloomCalculations.java:150)
>  .....
> I checked BloomCalculations class and following lines are responsible for 
> this exception:
> if (maxFalsePosProb < probs[maxBucketsPerElement][maxK]) {
>       throw new UnsupportedOperationException(String.format("Unable to 
> satisfy %s with %s buckets per element",
>                                                  maxFalsePosProb, 
> maxBucketsPerElement));
>   }
> From  the code it looks like a hard coaded validation (unless we can change 
> the nuber of buckets).
> So, if this validation is hard coaded then why it is even allowed to set such 
> value of bloom_fileter_fp_chance, that can prevent ssTable generation?
> Please correct this issue.



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

Reply via email to