[
https://issues.apache.org/jira/browse/CASSANDRA-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7088:
----------------------------------------
Attachment: 7088.txt
This is not a query validation problem. The fundamental problem is that we
made the mistake a long time ago of accepting an empty ByteBuffer as a valid
value for any type, and we now have to live with this. Except that
{{IntegerType.getString()}} was not handling it properly (more precisely, it's
{{IntegerSerializer.deserialize()}} that is called by
{{AbstractType.getString()}} that was not handling it). And the reason the
{{getString()}} method was called in the first place is because of the
tombstone log warning in {{SliceQueryFilter.collectReducedColumns()}} (which is
why 1.2 is not affected, that code is not there and we were never calling the
{{getString()}} method except maybe at DEBUG/TRACE).
So the proper fix is to handle empty values in
{{IntegerSerialize.deserialize()}} and attaching a patch for this. The patch
also clean up a bit the handling of null for getString/toString: most
serializer were handling it properly and using {{""}} as representation, but
{{AbstractType.getString()}} was somewhat overriding that behavior using
{{"null"}} as representation. Now, an empty string ({{""}}) is kind of a better
representation since that's how cqlsh will represent such value for instance,
so the patch fix that too by removing the special casing of null in
{{AbstractType.getString()}} (since it's the job of the serializer to handle
it) and make sure all serializer do handle it properly.
> Zero length BigInteger exception causing processing to freeze
> --------------------------------------------------------------
>
> Key: CASSANDRA-7088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7088
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux Mint 16
> Reporter: Jacek Furmankiewicz
> Assignee: Sylvain Lebresne
> Fix For: 2.0.8
>
> Attachments: 7088.txt, cassandra.yaml
>
>
> We attempted to migrate our developers to Cassandra 2.0.7 from 1.2.
> Everything worked perfectly, but we have experienced a massive drop in
> developer velocity.
> We run integration tests with Cucumber BDD and 1000 BDDs went from 7 minutes
> (Cassandra 1.2) to 15 minutes (2.0.7),
> This is when we run Cassandra of the ramdisk (/dev/shm) to make it run faster
> on dev boxes.
> When we tried pointed to actual drives the difference was dramatic: the
> entire suite took over 70 minutes (!) vs 15 in Cassandra 1.2.
> After investigation, we found that most of the time is spent in the
> truncation logic between every scenario, where we truncate all the column
> families and start with a clean DB for the next test case.
> This used to be super fast in 1.2, is now very slow in 2.0.
> It may not seem important, but upgrading to 2.0 has basically cut down
> developer velocity by 100%, just by more than doubling the time it takes to
> run our BDD suite.
> We truncate the CFs using the Ruby driver:
> $cassandra.column_families.each do |column_family|
> name = column_family[0].to_s
> $cassandra.truncate! name
> end
> I am attaching our cassandra.yaml. Please note we already switched off
> auto_compaction before truncate, just as we did in 1.2 for dev boxes, Made no
> difference.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
