[jira] [Commented] (CASSANDRA-10777) LegacySSTableTest Test-case failure, Issue with test\data\legacy-sstables\jb\Keyspace1\Keyspace1-Standard1-jb-0-Summary.db file read on BIG ENDian systems
[ https://issues.apache.org/jira/browse/CASSANDRA-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029565#comment-15029565 ] Michael Shuler commented on CASSANDRA-10777: I don't have a specific answer to endian-ness of the test sstable, but it's possible. Is there a big endian AWS instance type that can be used to replicate your result? This particular test has been stable on m3.xlarge instances. http://cassci.datastax.com/job/cassandra-2.2_utest/lastCompletedBuild/testReport/org.apache.cassandra.io.sstable/LegacySSTableTest/history/ > LegacySSTableTest Test-case failure, Issue with > test\data\legacy-sstables\jb\Keyspace1\Keyspace1-Standard1-jb-0-Summary.db > file read on BIG ENDian systems > > > Key: CASSANDRA-10777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10777 > Project: Cassandra > Issue Type: Bug > Environment: OS:RHEL7 and BIG ENDian system >Reporter: Nirav Thakkar > > I am building Cassandra 2.2.3 on BigEndian System. Cassandra builds > successfully. However there are quite a few test case failures. One of the > failing test case is LegacySSTableTest. This test case reads the file > test\data\legacy-sstables\jb\Keyspace1\Keyspace1-Standard1-jb-0-Summary.db > Are these existing test data files, specific to Little Endian systems? > I have observed differences in values read on a LE Vs BE systems. > I use the following command to run the test case. ant test > -Dtest.name=LegacySSTableTest > I get the following error: > [junit] - Standard Error - > [junit] Failed to read jb > [junit] - --- > [junit] Testcase: > testStreaming(org.apache.cassandra.io.sstable.LegacySSTableTest): FAILED > [junit] null > [junit] junit.framework.AssertionFailedError > [junit] at > org.apache.cassandra.io.sstable.IndexSummary.(IndexSummary.java:80) > [junit] at > org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:317) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:877) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:730) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:692) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:480) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:376) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:371) > [junit] at > org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:363) > [junit] at > org.apache.cassandra.io.sstable.LegacySSTableTest.testStreaming(LegacySSTableTest.java:115) > [junit] at > org.apache.cassandra.io.sstable.LegacySSTableTest.testStreaming(LegacySSTableTest.java:110) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Fix Version/s: 2.2.x
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 2.2.x, 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:20 AM:
{color:red}Note: no need to apply patch to {{v2.1}}. {color}
Applying the patch has the following benefits:
* {{v3.0}}: the NPE no longer occurs and the error message returned to the user
states that a MAP is not supported in cassandra-stress
* {{v2.2}}: the NPE no longer occurs. However, the error message returned to
the user is vague and does not mention the MAP type that caused the issue
* {{v2.1}}: no benefit
For versions 2.1 and 2.2 the root exception thrown from CFMetaData and CQL3Type
does not provide any useful information regarding data types, unlike the v3.0
root exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
was (Author: michaeledge):
{color:red}Note: no need to apply patch to {{v2.1}}. {color}
Applying the patch has the following benefits:
v3.0: the NPE no longer occurs and the error message returned to the user
states that a MAP is not supported in cassandra-stress
v2.2: the NPE no longer occurs. However, the error message returned to the user
is vague and does not mention the MAP type that caused the issue
v2.1: no benefit
For versions 2.1 and 2.2 the root exception thrown from CFMetaData and CQL3Type
does not provide any useful information regarding data types, unlike the v3.0
root exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
>
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:20 AM:
{color:red}Note: no need to apply patch to {{v2.1}}. {color}
Applying the patch has the following benefits:
v3.0: the NPE no longer occurs and the error message returned to the user
states that a MAP is not supported in cassandra-stress
v2.2: the NPE no longer occurs. However, the error message returned to the user
is vague and does not mention the MAP type that caused the issue
v2.1: no benefit
For versions 2.1 and 2.2 the root exception thrown from CFMetaData and CQL3Type
does not provide any useful information regarding data types, unlike the v3.0
root exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
was (Author: michaeledge):
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0 root
exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
>
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029430#comment-15029430
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:16 AM:
Patch for v2.2x and v3.x only
was (Author: michaeledge):
Patch for v3.x only
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029360#comment-15029360
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:15 AM:
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against v2.1, 2.2 and 3.0 with the following results:
* v2.1: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
* v2.2 and v3.0: NullPointerException
The piece of code causing the NPE is the same line of code that throws the
exception message seen in v2.1.
The exception is thrown by {{StressProfile.java}}, and the real root cause
exception depends on the Cassandra version:
{code}
v3.0
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
{code}
v2.1 and v2.2
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{code}
In v3.0 this exception is lost by the line of code in StressProfile.java that
re-throws the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}v2.2: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
{quote}
{quote}v3.0: There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for v2.2 and v3.0 attached - this solves the NPE and also provides an
understandable error message in v3.0. There is no need to apply this patch to
v2.1 as it provides no benefit.
was (Author: michaeledge):
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against v2.1, 2.2 and 3.0 with the following results:
* v2.1: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
* v2.2 and v3.0: NullPointerException
The piece of code causing the NPE is the same line of code that throws the
exception message seen in v2.1.
The exception is thrown by {{StressProfile.java}}, and the real root cause
exception depends on the Cassandra version:
{code}
v3.0
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
{code}
v2.1 and v2.2
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{code}
In v3.0 this exception is lost by the line of code in StressProfile.java that
re-throws the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}v2.2: There was a problem parsing the table cql:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{quote}
{quote}v3.0: There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for v2.2 and v3.0 attached - this solves the NPE and also provides an
understandable error message in v3.0. There is no need to apply this patch to
v2.1 as it provides no benefit.
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
>
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029360#comment-15029360
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:12 AM:
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against v2.1, 2.2 and 3.0 with the following results:
* v2.1: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
* v2.2 and v3.0: NullPointerException
The piece of code causing the NPE is the same line of code that throws the
exception message seen in v2.1.
The exception is thrown by {{StressProfile.java}}, and the real root cause
exception depends on the Cassandra version:
{code}
v3.0
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
{code}
v2.1 and v2.2
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{code}
In v3.0 this exception is lost by the line of code in StressProfile.java that
re-throws the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}v2.2: There was a problem parsing the table cql:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{quote}
{quote}v3.0: There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for v2.2 and v3.0 attached - this solves the NPE and also provides an
understandable error message in v3.0. There is no need to apply this patch to
v2.1 as it provides no benefit.
was (Author: michaeledge):
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against trunk and received a NullPointerException. However, the piece
of code causing the NPE is the same line of code that causes your {quote}There
was a problem parsing the table cql: Unknown keyspace autogeneratedtest{quote}
The exception is thrown by {{StressProfile.java}}, and the real underlying
exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
This exception is lost by the line of code in StressProfile.java that throws
the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for trunk attached.
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10
[jira] [Commented] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029486#comment-15029486
]
Amit Singh Chowdhery commented on CASSANDRA-10411:
--
Hi Team,
I think this will take CQL little closer to SQL and will allow little more
flexibility to user experience.
So I will pick this JIRA issue. I am thinking for the below changes(Just
blueprint) ::
Step 1: Change in Grammar src\java\org\apache\cassandra\cql3\Cql.g ,
altertablestatement will be changed for both ADD and DROP statements. it might
now look like :
For ADD -->
K_ADD ( { isStatic=true; } K_STATIC)? { type = AlterTableStatement.Type.ADD; }
c1=cident { mColumnName.add(c1); } v1=comparatorType {
mValidator.add(v1); }
( ',' cn=cident { mColumnName.add(cn); } vn=comparatorType
{ mValidator.add(vn); } )*
For DROP -->
K_DROP id=cident { mColumnName.add(id); } ( ',' cn=cident {
mColumnName.add(cn); } )* { type = AlterTableStatement.Type.DROP; }.
Step 2: After this corresponding java files will be changed to support above
grammar changes.
Requesting you all to provide Comments/suggestions for same.
Thanks
Amit Singh Chowdhery
> Add/drop multiple columns in one ALTER TABLE statement
> --
>
> Key: CASSANDRA-10411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10411
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Bryn Cooke
>Assignee: Amit Singh Chowdhery
>Priority: Minor
>
> Currently it is only possible to add one column at a time in an alter table
> statement. It would be great if we could add multiple columns at a time.
> The primary reason for this is that adding each column individually seems to
> take a significant amount of time (at least on my development machine), I
> know all the columns I want to add, but don't know them until after the
> initial table is created.
> As a secondary consideration it brings CQL slightly closer to SQL where most
> databases can handle adding multiple columns in one statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery reassigned CASSANDRA-10411: Assignee: Amit Singh Chowdhery > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10777) LegacySSTableTest Test-case failure, Issue with test\data\legacy-sstables\jb\Keyspace1\Keyspace1-Standard1-jb-0-Summary.db file read on BIG ENDian systems
Nirav Thakkar created CASSANDRA-10777: - Summary: LegacySSTableTest Test-case failure, Issue with test\data\legacy-sstables\jb\Keyspace1\Keyspace1-Standard1-jb-0-Summary.db file read on BIG ENDian systems Key: CASSANDRA-10777 URL: https://issues.apache.org/jira/browse/CASSANDRA-10777 Project: Cassandra Issue Type: Bug Environment: OS:RHEL7 and BIG ENDian system Reporter: Nirav Thakkar I am building Cassandra 2.2.3 on BigEndian System. Cassandra builds successfully. However there are quite a few test case failures. One of the failing test case is LegacySSTableTest. This test case reads the file test\data\legacy-sstables\jb\Keyspace1\Keyspace1-Standard1-jb-0-Summary.db Are these existing test data files, specific to Little Endian systems? I have observed differences in values read on a LE Vs BE systems. I use the following command to run the test case. ant test -Dtest.name=LegacySSTableTest I get the following error: [junit] - Standard Error - [junit] Failed to read jb [junit] - --- [junit] Testcase: testStreaming(org.apache.cassandra.io.sstable.LegacySSTableTest): FAILED [junit] null [junit] junit.framework.AssertionFailedError [junit] at org.apache.cassandra.io.sstable.IndexSummary.(IndexSummary.java:80) [junit] at org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:317) [junit] at org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:877) [junit] at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:730) [junit] at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:692) [junit] at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:480) [junit] at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:376) [junit] at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:371) [junit] at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:363) [junit] at org.apache.cassandra.io.sstable.LegacySSTableTest.testStreaming(LegacySSTableTest.java:115) [junit] at org.apache.cassandra.io.sstable.LegacySSTableTest.testStreaming(LegacySSTableTest.java:110) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 3:50 AM:
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0 root
exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
was (Author: michaeledge):
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0
underlying exception.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Fix Version/s: 3.x
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge commented on CASSANDRA-10725:
--
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0
underlying exception.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10753) Fix completion problems breaking clqshlib tests
[
https://issues.apache.org/jira/browse/CASSANDRA-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029366#comment-15029366
]
Stefania edited comment on CASSANDRA-10753 at 11/27/15 3:38 AM:
Thanks for your review:
bq. In test_timestamp_output since the TZ property is ignored I guess we can
just remove the second equals statement which is the same as the first. What do
you think?
Agreed, removed.
bq. The max_window_size_seconds problem is also affecting 2.2, could you
provide a 2.2 patch? (It's not on jenkins but since we'll still maintain 2.2
for some time, I guess we should fix it).
To fix 2.2 I think we need the entire patch since according to [~aholmber]
[comment|https://issues.apache.org/jira/browse/CASSANDRA-9302?focusedCommentId=15027191&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15027191]
on CASSANDRA-9302 we should be running the current driver. So I backported the
entire patch to 2.2 (via cherry-pick of individual commits) and then upgraded
the bundled driver to the same as 3.0. By the way, do you know which version it
is? I could not even find commit {{3f15725}} on any branch in the driver
repository. Shouldn't we upgrade to a later and more official version instead?
I also started noticing some timeout failures in the cqlshlib tests, on all
branches, when dropping keyspaces. I did not notice them before and I think
it's because I just migrated to a loan laptop where I installed Linux on an
hybrid HDD rather than SSD. It takes a crazy long time to flush all tables
before the final KEYSPACE DROPPED notification is sent to the driver. For 2.2 I
needed at least 20 seconds but for 3.0+ it took up to 35 seconds so I increased
the timeout to 45 seconds in 3.0+. Do you think this is normal?
Here are the patches and CI, but CASSCI is currently down so I cannot start any
jobs:
||2.2||3.0||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/10753-2.2]|[patch|https://github.com/stef1927/cassandra/commits/10753-3.0]|[patch|https://github.com/stef1927/cassandra/commits/10753]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-dtest/]|
I verified the cqlshlib tests pass locally on all branches _provided the driver
version installed is the same as the bundled version_. With 3.0rc1 installed,
{{TestCqlshCompletion.test_complete_in_delete}} failed the completion of a
clustering key in the where clause. I did not look further into this, we need
to confirm the correct driver version first.
I'll start the dtests as soon as CASSCI is back.
was (Author: stefania):
Thanks for your review:
bq. In test_timestamp_output since the TZ property is ignored I guess we can
just remove the second equals statement which is the same as the first. What do
you think?
Agreed, removed.
bq. The max_window_size_seconds problem is also affecting 2.2, could you
provide a 2.2 patch? (It's not on jenkins but since we'll still maintain 2.2
for some time, I guess we should fix it).
To fix 2.2 I think we need the entire patch since according to [~aholmber]
[comment|https://issues.apache.org/jira/browse/CASSANDRA-9302?focusedCommentId=15027191&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15027191]
on CASSANDRA-9302 we should be running the current driver. So I backported the
entire patch to 2.2 (via cherry-pick of individual commits) and then upgraded
the bundled driver to the same as 3.0. By the way, do you know which version it
is? I could not even find commit {{3f15725}} on any branch in the driver
repository. Shouldn't we upgrade to a later and more official version instead?
I also started noticing some timeout failures in the cqlshlib tests, on all
branches, when dropping keyspaces. I did not notice them before and I think
it's because I just migrated to a loan laptop where I installed Linux on an
hybrid HDD rather than SSD. It takes a crazy long time to flush all tables
before the final KEYSPACE DROPPED notification is sent to the driver. For 2.2 I
needed at least 20 seconds but for 3.0+ it took up to 35 seconds so I increased
the timeout to 45 seconds in 3.0+. Do you think this is normal?
Here are the patches and CI, but CASSCI is currently down so I cannot start any
jobs:
||2.2||3.0||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/10753-2.2]|[patch|https://github.com/stef1927/cassandra/commits/10753-3.0]|[patch|https://github.com/stef1927/cassandra/commits/10753]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-3.0-dtest/]|[dtest|http://cassci.datas
[jira] [Assigned] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge reassigned CASSANDRA-10725:
Assignee: Michael Edge
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Labels: stress tools (was: )
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Priority: Minor
> Labels: stress, tools
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Component/s: Tools
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Priority: Minor
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Attachment: CASSANDRA-3.0-10725-Cassandra-Stress.patch
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Priority: Minor
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10753) Fix completion problems breaking clqshlib tests
[
https://issues.apache.org/jira/browse/CASSANDRA-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029366#comment-15029366
]
Stefania commented on CASSANDRA-10753:
--
Thanks for your review:
bq. In test_timestamp_output since the TZ property is ignored I guess we can
just remove the second equals statement which is the same as the first. What do
you think?
Agreed, removed.
bq. The max_window_size_seconds problem is also affecting 2.2, could you
provide a 2.2 patch? (It's not on jenkins but since we'll still maintain 2.2
for some time, I guess we should fix it).
To fix 2.2 I think we need the entire patch since according to [~aholmber]
[comment|https://issues.apache.org/jira/browse/CASSANDRA-9302?focusedCommentId=15027191&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15027191]
on CASSANDRA-9302 we should be running the current driver. So I backported the
entire patch to 2.2 (via cherry-pick of individual commits) and then upgraded
the bundled driver to the same as 3.0. By the way, do you know which version it
is? I could not even find commit {{3f15725}} on any branch in the driver
repository. Shouldn't we upgrade to a later and more official version instead?
I also started noticing some timeout failures in the cqlshlib tests, on all
branches, when dropping keyspaces. I did not notice them before and I think
it's because I just migrated to a loan laptop where I installed Linux on an
hybrid HDD rather than SSD. It takes a crazy long time to flush all tables
before the final KEYSPACE DROPPED notification is sent to the driver. For 2.2 I
needed at least 20 seconds but for 3.0+ it took up to 35 seconds so I increased
the timeout to 45 seconds in 3.0+. Do you think this is normal?
Here are the patches and CI, but CASSCI is currently down so I cannot start any
jobs:
||2.2||3.0||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/10753-2.2]|[patch|https://github.com/stef1927/cassandra/commits/10753-3.0]|[patch|https://github.com/stef1927/cassandra/commits/10753]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10753-dtest/]|
I verified the cqlshlib tests locally on all branches. I'll start the dtests as
soon as CASSCI is back.
> Fix completion problems breaking clqshlib tests
> ---
>
> Key: CASSANDRA-10753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10753
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.x
>
>
> The recent changes in the python driver APIs have caused some completion
> problems as indicated by 2 of these failing tests:
> http://cassci.datastax.com/job/trunk_cqlshlib/579/testReport/
> The third failing test, {{test_timestamp_output}}, has been failing for some
> time due to uncertainty on what to do regarding timezone conversion but it
> too can be changed to reflect the fact that we convert the timestamp to UTC.
> Finally, {{max_window_size_seconds}} was recently added to the compaction
> properties and this caused 2 more tests to fail. It cannot be seen on Jenkins
> because of the relative import problem introduced by CASSANDRA-9304.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9302) Optimize cqlsh COPY FROM, part 3
[ https://issues.apache.org/jira/browse/CASSANDRA-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029368#comment-15029368 ] Stefania commented on CASSANDRA-9302: - Thanks, we'll address this on CASSANDRA-10753. > Optimize cqlsh COPY FROM, part 3 > > > Key: CASSANDRA-9302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9302 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Critical > Fix For: 2.1.x > > > We've had some discussion moving to Spark CSV import for bulk load in 3.x, > but people need a good bulk load tool now. One option is to add a separate > Java bulk load tool (CASSANDRA-9048), but if we can match that performance > from cqlsh I would prefer to leave COPY FROM as the preferred option to which > we point people, rather than adding more tools that need to be supported > indefinitely. > Previous work on COPY FROM optimization was done in CASSANDRA-7405 and > CASSANDRA-8225. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Priority: Minor (was: Major)
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Priority: Minor
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029360#comment-15029360
]
Michael Edge commented on CASSANDRA-10725:
--
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against trunk and received a NullPointerException. However, the piece
of code causing the NPE is the same line of code that causes your {quote}There
was a problem parsing the table cql: Unknown keyspace autogeneratedtest{quote}
The exception is thrown by {{StressProfile.java}}, and the real underlying
exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
This exception is lost by the line of code in StressProfile.java that throws
the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for trunk attached.
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10751) "Pool is shutdown" error when running Hadoop jobs on Yarn
[
https://issues.apache.org/jira/browse/CASSANDRA-10751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029330#comment-15029330
]
Cyril Scetbon commented on CASSANDRA-10751:
---
[~alexliu68] did you get any chance to have a look at it ?
> "Pool is shutdown" error when running Hadoop jobs on Yarn
> -
>
> Key: CASSANDRA-10751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10751
> Project: Cassandra
> Issue Type: Bug
> Environment: Hadoop 2.7.1 (HDP 2.3.2)
> Cassandra 2.1.11
>Reporter: Cyril Scetbon
>Assignee: Cyril Scetbon
> Attachments: CASSANDRA-10751-2.2.patch, CASSANDRA-10751-3.0.patch,
> output.log
>
>
> Trying to execute an Hadoop job on Yarn, I get errors from Cassandra's
> internal code. It seems that connections are shutdown but we can't understand
> why ...
> Here is a subtract of the errors. I also add a file with the complete debug
> logs.
> {code}
> 15/11/22 20:05:54 [main]: DEBUG core.RequestHandler: Error querying
> node006.internal.net/192.168.12.22:9042, trying next host (error is:
> com.datastax.driver.core.ConnectionException:
> [node006.internal.net/192.168.12.22:9042] Pool is shutdown)
> Failed with exception java.io.IOException:java.io.IOException:
> com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s)
> tried for query failed (tried: node006.internal.net/192.168.12.22:9042
> (com.datastax.driver.core.ConnectionException:
> [node006.internal.net/192.168.12.22:9042] Pool is shutdown))
> 15/11/22 20:05:54 [main]: ERROR CliDriver: Failed with exception
> java.io.IOException:java.io.IOException:
> com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s)
> tried for query failed (tried: node006.internal.net/192.168.12.22:9042
> (com.datastax.driver.core.ConnectionException:
> [node006.internal.net/192.168.12.22:9042] Pool is shutdown))
> java.io.IOException: java.io.IOException:
> com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s)
> tried for query failed (tried: node006.internal.net/192.168.12.22:9042
> (com.datastax.driver.core.ConnectionException:
> [node006.internal.net/192.168.12.22:9042] Pool is shutdown))
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.getNextRow(FetchOperator.java:508)
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.pushRow(FetchOperator.java:415)
> at org.apache.hadoop.hive.ql.exec.FetchTask.fetch(FetchTask.java:140)
> at org.apache.hadoop.hive.ql.Driver.getResults(Driver.java:1672)
> at
> org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java:233)
> at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:165)
> at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:376)
> at
> org.apache.hadoop.hive.cli.CliDriver.executeDriver(CliDriver.java:736)
> at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:681)
> at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:621)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
> at org.apache.hadoop.util.RunJar.main(RunJar.java:136)
> Caused by: java.io.IOException:
> com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s)
> tried for query failed (tried: node006.internal.net/192.168.12.22:9042
> (com.datastax.driver.core.ConnectionException:
> [node006.internal.net/192.168.12.22:9042] Pool is shutdown))
> at
> org.apache.hadoop.hive.cassandra.input.cql.HiveCqlInputFormat.getRecordReader(HiveCqlInputFormat.java:132)
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator$FetchInputFormatSplit.getRecordReader(FetchOperator.java:674)
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.getRecordReader(FetchOperator.java:324)
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.getNextRow(FetchOperator.java:446)
> ... 15 more
> Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All
> host(s) tried for query failed (tried:
> node006.internal.net/192.168.12.22:9042
> (com.datastax.driver.core.ConnectionException:
> [node006.internal.net/192.168.12.22:9042] Pool is shutdown))
> at
> com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:84)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> at
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture
[jira] [Commented] (CASSANDRA-9748) Can't see other nodes when using multiple network interfaces
[
https://issues.apache.org/jira/browse/CASSANDRA-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029271#comment-15029271
]
Paulo Motta commented on CASSANDRA-9748:
Actually the solution is much simpler than initially thought, and requires
little change in code and documentation.
The idea is to provide a new property {{listen_on_broadcast_address}}, which
should be enabled for who wants to listen on both {{listen_address}} and
{{broadcast_address}}, in network environments which do not automatically route
from the public to the private address, such as outside EC2. The benefits of
this approach is that the [multiple network interfaces
documentation|http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configMultiNetworks.html]
requires little change, just a note asking users to enable
{{listen_on_broadcast_address}} property if they're using multiple physical
interfaces. Furthermore, no changes are required to
{{GossipingPropertyFileSnitch}} which already re-routes traffic from
{{broadcast_address}} to {{listen_address}} when the {{prefer_local}} is
enabled, so it's done.
Changing {{listen_address}} to receive a list wouldn't be a good idea because
it would require a change to system keyspace and associated schema migrations.
Furthermore there are other places around the code that use this property so
this would break them (and maybe drivers as well). Adding a
{{local_listen_address}} would require a different documentation for EC2 and
multiple physical network interfaces, and would add more complexity, since we
already have {{listen_address}} and {{broadcast_address}} exactly for this use
case already, so no need to introduce a third address in addition to those.
I created a [dtest|https://github.com/riptano/cassandra-dtest/pull/687] that
tests {{listen_on_broadcast_address}} and also the {{prefer_local}} property of
{{GossipingPropertyFileSnitch}}.
The change is so small and independent that I think we can include it in 2.1.
I'm not sure if it should go into 3.0.1/3.1, but submitted tests anyway, so
will let the committer/reviewer decide.
There was another user recently [on the mailing
list|https://www.mail-archive.com/user@cassandra.apache.org/msg44987.html]
unable to setup multiple network interfaces due to this limitation, so I think
it has non-negligible demand.
||2.1||2.2||3.0||trunk||dtest||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:9478-2.1-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:9478-2.2-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:9478-3.0-v2]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:9478-trunk-v2]|[branch|https://github.com/riptano/cassandra-dtest/compare/master...pauloricardomg:9748]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-2.1-v2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-2.2-v2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-3.0-v2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-trunk-v2-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-2.1-v2-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-2.2-v2-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-3.0-v2-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9478-trunk-v2-dtest/lastCompletedBuild/testReport/]|
> Can't see other nodes when using multiple network interfaces
>
>
> Key: CASSANDRA-9748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9748
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
> Environment: Cassandra 2.0.16; multi-DC configuration
>Reporter: Roman Bielik
>Assignee: Paulo Motta
>Priority: Minor
> Labels: docs-impacting
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: system_node1.log, system_node2.log
>
>
> The idea is to setup a multi-DC environment across 2 different networks based
> on the following configuration recommendations:
> http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configMultiNetworks.html
> Each node has 2 network interfaces. One used as a private network (DC1:
> 10.0.1.x and DC2: 10.0.2.x). The
[jira] [Commented] (CASSANDRA-9669) If sstable flushes complete out of order, on restart we can fail to replay necessary commit log records
[
https://issues.apache.org/jira/browse/CASSANDRA-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029168#comment-15029168
]
Branimir Lambov commented on CASSANDRA-9669:
Rebased and uploaded
[here|https://github.com/blambov/cassandra/tree/belliottsmith-9669-2.2].
[Testall|http://cassci.datastax.com/job/blambov-belliottsmith-9669-2.2-testall/]
is clean,
[dtest|http://cassci.datastax.com/job/blambov-belliottsmith-9669-2.2-dtest/]
has a [test_closing_connections
failure|http://cassci.datastax.com/job/blambov-belliottsmith-9669-2.2-dtest/lastCompletedBuild/testReport/thrift_hsha_test/ThriftHSHATest/test_closing_connections/].
> If sstable flushes complete out of order, on restart we can fail to replay
> necessary commit log records
> ---
>
> Key: CASSANDRA-9669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9669
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benedict
>Assignee: Benedict
>Priority: Critical
> Labels: correctness
> Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1
>
>
> While {{postFlushExecutor}} ensures it never expires CL entries out-of-order,
> on restart we simply take the maximum replay position of any sstable on disk,
> and ignore anything prior.
> It is quite possible for there to be two flushes triggered for a given table,
> and for the second to finish first by virtue of containing a much smaller
> quantity of live data (or perhaps the disk is just under less pressure). If
> we crash before the first sstable has been written, then on restart the data
> it would have represented will disappear, since we will not replay the CL
> records.
> This looks to be a bug present since time immemorial, and also seems pretty
> serious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10761) Possible regression of CASSANDRA-9201
[
https://issues.apache.org/jira/browse/CASSANDRA-10761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029146#comment-15029146
]
Sam Tunnicliffe commented on CASSANDRA-10761:
-
bq. We should not add then initialize, we should initialize then add.
Yes, that makes much more sense. I've rebased and force pushed versions with
that change, let's see if the CI runs show anything.
> Possible regression of CASSANDRA-9201
> -
>
> Key: CASSANDRA-10761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10761
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.1, 3.1, 2.2.x
>
> Attachments: 10761-logs.tar.gz
>
>
> Some dtests like
> {{consistency_test.TestAccuracy.test_network_topology_strategy_each_quorum_counters}}
> are failing with the follow auth related assertion exception
> {code}
> [node6 ERROR] java.lang.AssertionError:
> org.apache.cassandra.exceptions.InvalidRequestException: unconfigured table
> roles
> at
> org.apache.cassandra.auth.CassandraRoleManager.prepare(CassandraRoleManager.java:450)
> at
> org.apache.cassandra.auth.CassandraRoleManager.setup(CassandraRoleManager.java:144)
> at
> org.apache.cassandra.service.StorageService.doAuthSetup(StorageService.java:1036)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:984)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:708)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:345)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:561)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> Caused by: org.apache.cassandra.exceptions.InvalidRequestException:
> unconfigured table roles
> at
> org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily(ThriftValidation.java:114)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:757)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:752)
> at
> org.apache.cassandra.auth.CassandraRoleManager.prepare(CassandraRoleManager.java:446)
> ... 8 more
> {code}
> This looks very similar to CASSANDRA-9201.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10729) SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT return wrong results
[
https://issues.apache.org/jira/browse/CASSANDRA-10729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-10729:
---
Component/s: CQL
> SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT
> return wrong results
> --
>
> Key: CASSANDRA-10729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10729
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0.1, 3.1, 3.2
>
> Attachments: 10729-3.0-V2.txt, 10729-3.0.txt
>
>
> If we execute a request with paging turned off, an IN restriction on the
> partition key, ORDER BY and LIMIT the result returned are not the expected
> ones.
> The following test can be used to reproduce the problem.
> {code}
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, v text,
> PRIMARY KEY ((pk1, pk2), c) )");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 2, "A");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 2,
> 1, "B");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 3,
> 3, "C");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 4, "D");
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c; ", 1, 1, 2),
>row("B"),
>row("A"),
>row("D"));
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c LIMIT 2; ", 1, 1, 2),
>row("B"),
>row("A"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[1/2] cassandra git commit: Ninja Fix: remove separator in CHANGES.txt
Repository: cassandra Updated Branches: refs/heads/trunk f8153a1d6 -> 20eedd0bd Ninja Fix: remove separator in CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9631ac1a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9631ac1a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9631ac1a Branch: refs/heads/trunk Commit: 9631ac1a0ed6853bd7131daf8bd33ae79a674ee8 Parents: e3113c9 Author: Benjamin Lerer Authored: Thu Nov 26 17:55:28 2015 +0100 Committer: Benjamin Lerer Committed: Thu Nov 26 17:55:28 2015 +0100 -- CHANGES.txt | 1 - 1 file changed, 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9631ac1a/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 5ea2b45..c9f3c38 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,7 +1,6 @@ 3.1 Merged from 3.0: -=== * Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT (CASSANDRA-10729) * Improve stress performance over 1k threads (CASSANDRA-7217)
[2/2] cassandra git commit: Merge remote-tracking branch 'asf/cassandra-3.1' into trunk
Merge remote-tracking branch 'asf/cassandra-3.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/20eedd0b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/20eedd0b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/20eedd0b Branch: refs/heads/trunk Commit: 20eedd0bd1d11a61cf08ef706cb2f0d44465c785 Parents: f8153a1 9631ac1 Author: Benjamin Lerer Authored: Thu Nov 26 17:57:43 2015 +0100 Committer: Benjamin Lerer Committed: Thu Nov 26 17:57:43 2015 +0100 -- --
cassandra git commit: Ninja Fix: remove separator in CHANGES.txt
Repository: cassandra Updated Branches: refs/heads/cassandra-3.1 e3113c947 -> 9631ac1a0 Ninja Fix: remove separator in CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9631ac1a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9631ac1a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9631ac1a Branch: refs/heads/cassandra-3.1 Commit: 9631ac1a0ed6853bd7131daf8bd33ae79a674ee8 Parents: e3113c9 Author: Benjamin Lerer Authored: Thu Nov 26 17:55:28 2015 +0100 Committer: Benjamin Lerer Committed: Thu Nov 26 17:55:28 2015 +0100 -- CHANGES.txt | 1 - 1 file changed, 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9631ac1a/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 5ea2b45..c9f3c38 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,7 +1,6 @@ 3.1 Merged from 3.0: -=== * Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT (CASSANDRA-10729) * Improve stress performance over 1k threads (CASSANDRA-7217)
[6/7] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.1
Merge branch cassandra-3.0 into cassandra-3.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e3113c94 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e3113c94 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e3113c94 Branch: refs/heads/trunk Commit: e3113c9476138dbcfab05abf98f560b9c1e33ad1 Parents: 0e5aa51 7e6c1d5 Author: Benjamin Lerer Authored: Thu Nov 26 17:44:39 2015 +0100 Committer: Benjamin Lerer Committed: Thu Nov 26 17:44:39 2015 +0100 -- CHANGES.txt | 4 + NEWS.txt| 9 ++ .../cql3/statements/SelectStatement.java| 91 ++-- .../apache/cassandra/db/filter/DataLimits.java | 20 +++-- .../operations/SelectOrderByTest.java | 41 + 5 files changed, 129 insertions(+), 36 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e3113c94/CHANGES.txt -- diff --cc CHANGES.txt index e0d578d,e1a959a..5ea2b45 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,5 -1,6 +1,9 @@@ -3.0.1 ++ +3.1 +Merged from 3.0: ++=== + * Fix SELECT statement with IN restrictions on partition key, +ORDER BY and LIMIT (CASSANDRA-10729) * Improve stress performance over 1k threads (CASSANDRA-7217) * Wait for migration responses to complete before bootstrapping (CASSANDRA-10731) * Unable to create a function with argument of type Inet (CASSANDRA-10741)
[3/7] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f4dab0f9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f4dab0f9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f4dab0f9 Branch: refs/heads/trunk Commit: f4dab0f9b3a037c952aaa71219987eb4f44535e5 Parents: 64a3bfd e4f3dba Author: Sylvain Lebresne Authored: Thu Nov 26 15:44:18 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:44:18 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f4dab0f9/CHANGES.txt -- diff --cc CHANGES.txt index 04cda25,d31645a..eab04fb --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -14,7 -4,16 +14,8 @@@ Merged from 2.2 * Fix SimpleDateType type compatibility (CASSANDRA-10027) * (Hadoop) fix splits calculation (CASSANDRA-10640) * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) - * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) - * Use most up-to-date version of schema for system tables (CASSANDRA-10652) - * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) - * Expose phi values from failure detector via JMX and tweak debug - and trace logging (CASSANDRA-9526) - * Fix RangeNamesQueryPager (CASSANDRA-10509) - * Deprecate Pig support (CASSANDRA-10542) - * Reduce contention getting instances of CompositeType (CASSANDRA-10433) Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
[1/7] cassandra git commit: Force encoding charset when computed prepared statement IDs
Repository: cassandra
Updated Branches:
refs/heads/trunk 4901af68a -> f8153a1d6
Force encoding charset when computed prepared statement IDs
patch by Stefan Podkowinski; reviewed by slebresne for CASSANDRA-10755
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5b9f710
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5b9f710
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5b9f710
Branch: refs/heads/trunk
Commit: b5b9f7106d66eda6e41cea292bc569886b701448
Parents: cdf0485
Author: Stefan Podkowinski
Authored: Mon Nov 23 17:12:35 2015 +0100
Committer: Sylvain Lebresne
Committed: Thu Nov 26 11:02:30 2015 +0100
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7978a56..ee0bc61 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.12
+ * Force encoding when computing statement ids (CASSANDRA-10755)
* Properly reject counters as map keys (CASSANDRA-10760)
* Fix the sstable-needs-cleanup check (CASSANDRA-10740)
* (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/src/java/org/apache/cassandra/utils/MD5Digest.java
--
diff --git a/src/java/org/apache/cassandra/utils/MD5Digest.java
b/src/java/org/apache/cassandra/utils/MD5Digest.java
index 3f46458..2dc57de 100644
--- a/src/java/org/apache/cassandra/utils/MD5Digest.java
+++ b/src/java/org/apache/cassandra/utils/MD5Digest.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.utils;
+import java.io.UnsupportedEncodingException;
import java.util.Arrays;
/**
@@ -50,7 +51,14 @@ public class MD5Digest
public static MD5Digest compute(String toHash)
{
-return compute(toHash.getBytes());
+try
+{
+return compute(toHash.getBytes("UTF-8"));
+}
+catch (UnsupportedEncodingException e)
+{
+throw new RuntimeException(e.getMessage());
+}
}
@Override
[7/7] cassandra git commit: Merge branch cassandra-3.1 into trunk
Merge branch cassandra-3.1 into trunk
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f8153a1d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f8153a1d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f8153a1d
Branch: refs/heads/trunk
Commit: f8153a1d6b30dd7bdc66c136d5c2e3ec434a9acb
Parents: 4901af6 e3113c9
Author: Benjamin Lerer
Authored: Thu Nov 26 17:52:52 2015 +0100
Committer: Benjamin Lerer
Committed: Thu Nov 26 17:52:52 2015 +0100
--
CHANGES.txt | 3 +
NEWS.txt| 10 +++
.../cql3/statements/SelectStatement.java| 91 ++--
.../apache/cassandra/db/filter/DataLimits.java | 20 +++--
.../operations/SelectOrderByTest.java | 41 +
5 files changed, 129 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8153a1d/CHANGES.txt
--
diff --cc CHANGES.txt
index 41609cf,5ea2b45..83212d7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,17 -1,9 +1,20 @@@
+3.2
+ * Make compression ratio much more accurate (CASSANDRA-10225)
+ * Optimize building of Clustering object when only one is created
(CASSANDRA-10409)
+ * Make index building pluggable (CASSANDRA-10681)
+ * Add sstable flush observer (CASSANDRA-10678)
+ * Improve NTS endpoints calculation (CASSANDRA-10200)
+ * Improve performance of the folderSize function (CASSANDRA-10677)
+ * Add support for type casting in selection clause (CASSANDRA-10310)
+ * Added graphing option to cassandra-stress (CASSANDRA-7918)
+ * Abort in-progress queries that time out (CASSANDRA-7392)
+ * Add transparent data encryption core classes (CASSANDRA-9945)
+
+
3.1
Merged from 3.0:
-===
+ * Fix SELECT statement with IN restrictions on partition key,
+ORDER BY and LIMIT (CASSANDRA-10729)
* Improve stress performance over 1k threads (CASSANDRA-7217)
* Wait for migration responses to complete before bootstrapping
(CASSANDRA-10731)
* Unable to create a function with argument of type Inet (CASSANDRA-10741)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8153a1d/NEWS.txt
--
diff --cc NEWS.txt
index 2ccc27d,02a9525..c71ff1a
--- a/NEWS.txt
+++ b/NEWS.txt
@@@ -13,18 -13,15 +13,28 @@@ restore snapshots created with the prev
'sstableloader' tool. You can upgrade the file format of your snapshots
using the provided 'sstableupgrade' tool.
+3.2
+===
+
+New features
+
+
+ - Support for type casting has been added to the selection clause.
+
+Upgrading
+-
+ - The compression ratio metrics computation has been modified to be more
accurate.
+
++
+ 3.0.1
+ =
+
+ Upgrading
+ -
+- The return value of SelectStatement::getLimit as been changed from
DataLimits
+ to int.
+
+
3.0
===
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8153a1d/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 03dca2d,a9bb121..cec8bcb
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@@ -375,22 -391,23 +391,23 @@@ public class SelectStatement implement
public ResultMessage.Rows executeInternal(QueryState state, QueryOptions
options) throws RequestExecutionException, RequestValidationException
{
int nowInSec = FBUtilities.nowInSeconds();
- ReadQuery query = getQuery(options, nowInSec);
+ int userLimit = getLimit(options);
+ ReadQuery query = getQuery(options, nowInSec, userLimit);
int pageSize = getPageSize(options);
-try (ReadOrderGroup orderGroup = query.startOrderGroup())
+try (ReadExecutionController executionController =
query.executionController())
{
if (pageSize <= 0 || query.limits().count() <= pageSize)
{
-try (PartitionIterator data =
query.executeInternal(orderGroup))
+try (PartitionIterator data =
query.executeInternal(executionController))
{
- return processResults(data, options, nowInSec);
+ return processResults(data, options, nowInSec, userLimit);
}
}
else
{
QueryPager pager = query.getPager(options.getPagingState(),
options.getProtocolVersion());
- return execute(Pager.forInternalQuery(pager,
executionController
[4/7] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.1
Merge branch 'cassandra-3.0' into cassandra-3.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0e5aa51d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0e5aa51d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0e5aa51d Branch: refs/heads/trunk Commit: 0e5aa51d1222b5d4434b6c79e41931332e58a7f4 Parents: b7ead2b f4dab0f Author: Sylvain Lebresne Authored: Thu Nov 26 15:44:44 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:44:44 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5aa51d/CHANGES.txt --
[2/7] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4f3dbac Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4f3dbac Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4f3dbac Branch: refs/heads/trunk Commit: e4f3dbac02471cf69d4e525fc24cc288de32ed73 Parents: 8bfdd65 b5b9f71 Author: Sylvain Lebresne Authored: Thu Nov 26 15:43:55 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:43:55 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4f3dbac/CHANGES.txt -- diff --cc CHANGES.txt index 237c251,ee0bc61..d31645a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,18 -1,5 +1,19 @@@ -2.1.12 +2.2.4 + * Fix JSON update with prepared statements (CASSANDRA-10631) + * Don't do anticompaction after subrange repair (CASSANDRA-10422) + * Fix SimpleDateType type compatibility (CASSANDRA-10027) + * (Hadoop) fix splits calculation (CASSANDRA-10640) + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) + * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) + * Use most up-to-date version of schema for system tables (CASSANDRA-10652) + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) + * Expose phi values from failure detector via JMX and tweak debug + and trace logging (CASSANDRA-9526) + * Fix RangeNamesQueryPager (CASSANDRA-10509) + * Deprecate Pig support (CASSANDRA-10542) + * Reduce contention getting instances of CompositeType (CASSANDRA-10433) +Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
[5/7] cassandra git commit: Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT
Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT
patch by Benjamin Lerer; reviewed by Sylvain Lebresne for CASSANDRA-10729
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e6c1d54
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e6c1d54
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e6c1d54
Branch: refs/heads/trunk
Commit: 7e6c1d5483b35ab93dff0f5fd559760d733b
Parents: f4dab0f
Author: Benjamin Lerer
Authored: Thu Nov 26 17:40:33 2015 +0100
Committer: Benjamin Lerer
Committed: Thu Nov 26 17:40:33 2015 +0100
--
CHANGES.txt | 2 +
NEWS.txt| 9 ++
.../cql3/statements/SelectStatement.java| 91 ++--
.../apache/cassandra/db/filter/DataLimits.java | 20 +++--
.../operations/SelectOrderByTest.java | 41 +
5 files changed, 127 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eab04fb..e1a959a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
3.0.1
+ * Fix SELECT statement with IN restrictions on partition key,
+ ORDER BY and LIMIT (CASSANDRA-10729)
* Improve stress performance over 1k threads (CASSANDRA-7217)
* Wait for migration responses to complete before bootstrapping
(CASSANDRA-10731)
* Unable to create a function with argument of type Inet (CASSANDRA-10741)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d971d5e..02a9525 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,15 @@ restore snapshots created with the previous major version
using the
'sstableloader' tool. You can upgrade the file format of your snapshots
using the provided 'sstableupgrade' tool.
+3.0.1
+=
+
+Upgrading
+-
+ - The return value of SelectStatement::getLimit as been changed from
DataLimits
+ to int.
+
+
3.0
===
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index ab1da45..a9bb121 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -202,15 +202,16 @@ public class SelectStatement implements CQLStatement
cl.validateForRead(keyspace());
int nowInSec = FBUtilities.nowInSeconds();
-ReadQuery query = getQuery(options, nowInSec);
+int userLimit = getLimit(options);
+ReadQuery query = getQuery(options, nowInSec, userLimit);
int pageSize = getPageSize(options);
if (pageSize <= 0 || query.limits().count() <= pageSize)
-return execute(query, options, state, nowInSec);
+return execute(query, options, state, nowInSec, userLimit);
QueryPager pager = query.getPager(options.getPagingState(),
options.getProtocolVersion());
-return execute(Pager.forDistributedQuery(pager, cl,
state.getClientState()), options, pageSize, nowInSec);
+return execute(Pager.forDistributedQuery(pager, cl,
state.getClientState()), options, pageSize, nowInSec, userLimit);
}
private int getPageSize(QueryOptions options)
@@ -228,18 +229,27 @@ public class SelectStatement implements CQLStatement
public ReadQuery getQuery(QueryOptions options, int nowInSec) throws
RequestValidationException
{
-DataLimits limit = getLimit(options);
+return getQuery(options, nowInSec, getLimit(options));
+}
+
+public ReadQuery getQuery(QueryOptions options, int nowInSec, int
userLimit) throws RequestValidationException
+{
+DataLimits limit = getDataLimits(userLimit);
if (restrictions.isKeyRange() || restrictions.usesSecondaryIndexing())
return getRangeCommand(options, limit, nowInSec);
return getSliceCommands(options, limit, nowInSec);
}
-private ResultMessage.Rows execute(ReadQuery query, QueryOptions options,
QueryState state, int nowInSec) throws RequestValidationException,
RequestExecutionException
+private ResultMessage.Rows execute(ReadQuery query,
+ QueryOptions options,
+ QueryState state,
+ int nowInSec,
+
[1/2] cassandra git commit: Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.1 0e5aa51d1 -> e3113c947
Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT
patch by Benjamin Lerer; reviewed by Sylvain Lebresne for CASSANDRA-10729
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e6c1d54
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e6c1d54
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e6c1d54
Branch: refs/heads/cassandra-3.1
Commit: 7e6c1d5483b35ab93dff0f5fd559760d733b
Parents: f4dab0f
Author: Benjamin Lerer
Authored: Thu Nov 26 17:40:33 2015 +0100
Committer: Benjamin Lerer
Committed: Thu Nov 26 17:40:33 2015 +0100
--
CHANGES.txt | 2 +
NEWS.txt| 9 ++
.../cql3/statements/SelectStatement.java| 91 ++--
.../apache/cassandra/db/filter/DataLimits.java | 20 +++--
.../operations/SelectOrderByTest.java | 41 +
5 files changed, 127 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eab04fb..e1a959a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
3.0.1
+ * Fix SELECT statement with IN restrictions on partition key,
+ ORDER BY and LIMIT (CASSANDRA-10729)
* Improve stress performance over 1k threads (CASSANDRA-7217)
* Wait for migration responses to complete before bootstrapping
(CASSANDRA-10731)
* Unable to create a function with argument of type Inet (CASSANDRA-10741)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d971d5e..02a9525 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,15 @@ restore snapshots created with the previous major version
using the
'sstableloader' tool. You can upgrade the file format of your snapshots
using the provided 'sstableupgrade' tool.
+3.0.1
+=
+
+Upgrading
+-
+ - The return value of SelectStatement::getLimit as been changed from
DataLimits
+ to int.
+
+
3.0
===
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index ab1da45..a9bb121 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -202,15 +202,16 @@ public class SelectStatement implements CQLStatement
cl.validateForRead(keyspace());
int nowInSec = FBUtilities.nowInSeconds();
-ReadQuery query = getQuery(options, nowInSec);
+int userLimit = getLimit(options);
+ReadQuery query = getQuery(options, nowInSec, userLimit);
int pageSize = getPageSize(options);
if (pageSize <= 0 || query.limits().count() <= pageSize)
-return execute(query, options, state, nowInSec);
+return execute(query, options, state, nowInSec, userLimit);
QueryPager pager = query.getPager(options.getPagingState(),
options.getProtocolVersion());
-return execute(Pager.forDistributedQuery(pager, cl,
state.getClientState()), options, pageSize, nowInSec);
+return execute(Pager.forDistributedQuery(pager, cl,
state.getClientState()), options, pageSize, nowInSec, userLimit);
}
private int getPageSize(QueryOptions options)
@@ -228,18 +229,27 @@ public class SelectStatement implements CQLStatement
public ReadQuery getQuery(QueryOptions options, int nowInSec) throws
RequestValidationException
{
-DataLimits limit = getLimit(options);
+return getQuery(options, nowInSec, getLimit(options));
+}
+
+public ReadQuery getQuery(QueryOptions options, int nowInSec, int
userLimit) throws RequestValidationException
+{
+DataLimits limit = getDataLimits(userLimit);
if (restrictions.isKeyRange() || restrictions.usesSecondaryIndexing())
return getRangeCommand(options, limit, nowInSec);
return getSliceCommands(options, limit, nowInSec);
}
-private ResultMessage.Rows execute(ReadQuery query, QueryOptions options,
QueryState state, int nowInSec) throws RequestValidationException,
RequestExecutionException
+private ResultMessage.Rows execute(ReadQuery query,
+ QueryOptions options,
+
[2/2] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.1
Merge branch cassandra-3.0 into cassandra-3.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e3113c94 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e3113c94 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e3113c94 Branch: refs/heads/cassandra-3.1 Commit: e3113c9476138dbcfab05abf98f560b9c1e33ad1 Parents: 0e5aa51 7e6c1d5 Author: Benjamin Lerer Authored: Thu Nov 26 17:44:39 2015 +0100 Committer: Benjamin Lerer Committed: Thu Nov 26 17:44:39 2015 +0100 -- CHANGES.txt | 4 + NEWS.txt| 9 ++ .../cql3/statements/SelectStatement.java| 91 ++-- .../apache/cassandra/db/filter/DataLimits.java | 20 +++-- .../operations/SelectOrderByTest.java | 41 + 5 files changed, 129 insertions(+), 36 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e3113c94/CHANGES.txt -- diff --cc CHANGES.txt index e0d578d,e1a959a..5ea2b45 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,5 -1,6 +1,9 @@@ -3.0.1 ++ +3.1 +Merged from 3.0: ++=== + * Fix SELECT statement with IN restrictions on partition key, +ORDER BY and LIMIT (CASSANDRA-10729) * Improve stress performance over 1k threads (CASSANDRA-7217) * Wait for migration responses to complete before bootstrapping (CASSANDRA-10731) * Unable to create a function with argument of type Inet (CASSANDRA-10741)
cassandra git commit: Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 f4dab0f9b -> 7e6c1d548
Fix SELECT statement with IN restrictions on partition key, ORDER BY and LIMIT
patch by Benjamin Lerer; reviewed by Sylvain Lebresne for CASSANDRA-10729
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e6c1d54
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e6c1d54
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e6c1d54
Branch: refs/heads/cassandra-3.0
Commit: 7e6c1d5483b35ab93dff0f5fd559760d733b
Parents: f4dab0f
Author: Benjamin Lerer
Authored: Thu Nov 26 17:40:33 2015 +0100
Committer: Benjamin Lerer
Committed: Thu Nov 26 17:40:33 2015 +0100
--
CHANGES.txt | 2 +
NEWS.txt| 9 ++
.../cql3/statements/SelectStatement.java| 91 ++--
.../apache/cassandra/db/filter/DataLimits.java | 20 +++--
.../operations/SelectOrderByTest.java | 41 +
5 files changed, 127 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eab04fb..e1a959a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
3.0.1
+ * Fix SELECT statement with IN restrictions on partition key,
+ ORDER BY and LIMIT (CASSANDRA-10729)
* Improve stress performance over 1k threads (CASSANDRA-7217)
* Wait for migration responses to complete before bootstrapping
(CASSANDRA-10731)
* Unable to create a function with argument of type Inet (CASSANDRA-10741)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index d971d5e..02a9525 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,15 @@ restore snapshots created with the previous major version
using the
'sstableloader' tool. You can upgrade the file format of your snapshots
using the provided 'sstableupgrade' tool.
+3.0.1
+=
+
+Upgrading
+-
+ - The return value of SelectStatement::getLimit as been changed from
DataLimits
+ to int.
+
+
3.0
===
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e6c1d54/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index ab1da45..a9bb121 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -202,15 +202,16 @@ public class SelectStatement implements CQLStatement
cl.validateForRead(keyspace());
int nowInSec = FBUtilities.nowInSeconds();
-ReadQuery query = getQuery(options, nowInSec);
+int userLimit = getLimit(options);
+ReadQuery query = getQuery(options, nowInSec, userLimit);
int pageSize = getPageSize(options);
if (pageSize <= 0 || query.limits().count() <= pageSize)
-return execute(query, options, state, nowInSec);
+return execute(query, options, state, nowInSec, userLimit);
QueryPager pager = query.getPager(options.getPagingState(),
options.getProtocolVersion());
-return execute(Pager.forDistributedQuery(pager, cl,
state.getClientState()), options, pageSize, nowInSec);
+return execute(Pager.forDistributedQuery(pager, cl,
state.getClientState()), options, pageSize, nowInSec, userLimit);
}
private int getPageSize(QueryOptions options)
@@ -228,18 +229,27 @@ public class SelectStatement implements CQLStatement
public ReadQuery getQuery(QueryOptions options, int nowInSec) throws
RequestValidationException
{
-DataLimits limit = getLimit(options);
+return getQuery(options, nowInSec, getLimit(options));
+}
+
+public ReadQuery getQuery(QueryOptions options, int nowInSec, int
userLimit) throws RequestValidationException
+{
+DataLimits limit = getDataLimits(userLimit);
if (restrictions.isKeyRange() || restrictions.usesSecondaryIndexing())
return getRangeCommand(options, limit, nowInSec);
return getSliceCommands(options, limit, nowInSec);
}
-private ResultMessage.Rows execute(ReadQuery query, QueryOptions options,
QueryState state, int nowInSec) throws RequestValidationException,
RequestExecutionException
+private ResultMessage.Rows execute(ReadQuery query,
+ QueryOptions options,
+
[jira] [Updated] (CASSANDRA-10729) SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT return wrong results
[
https://issues.apache.org/jira/browse/CASSANDRA-10729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-10729:
---
Attachment: 10729-3.0-V2.txt
> SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT
> return wrong results
> --
>
> Key: CASSANDRA-10729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10729
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0.1, 3.1, 3.2
>
> Attachments: 10729-3.0-V2.txt, 10729-3.0.txt
>
>
> If we execute a request with paging turned off, an IN restriction on the
> partition key, ORDER BY and LIMIT the result returned are not the expected
> ones.
> The following test can be used to reproduce the problem.
> {code}
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, v text,
> PRIMARY KEY ((pk1, pk2), c) )");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 2, "A");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 2,
> 1, "B");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 3,
> 3, "C");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 4, "D");
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c; ", 1, 1, 2),
>row("B"),
>row("A"),
>row("D"));
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c LIMIT 2; ", 1, 1, 2),
>row("B"),
>row("A"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9669) If sstable flushes complete out of order, on restart we can fail to replay necessary commit log records
[
https://issues.apache.org/jira/browse/CASSANDRA-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029053#comment-15029053
]
Sylvain Lebresne commented on CASSANDRA-9669:
-
[~blambov] As Benedict is currently out, do you mind pushing the branch with
your nit fixed and running CI on it to be sure (as I don't see a recent CI run
for this).
> If sstable flushes complete out of order, on restart we can fail to replay
> necessary commit log records
> ---
>
> Key: CASSANDRA-9669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9669
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benedict
>Assignee: Benedict
>Priority: Critical
> Labels: correctness
> Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1
>
>
> While {{postFlushExecutor}} ensures it never expires CL entries out-of-order,
> on restart we simply take the maximum replay position of any sstable on disk,
> and ignore anything prior.
> It is quite possible for there to be two flushes triggered for a given table,
> and for the second to finish first by virtue of containing a much smaller
> quantity of live data (or perhaps the disk is just under less pressure). If
> we crash before the first sstable has been written, then on restart the data
> it would have represented will disappear, since we will not replay the CL
> records.
> This looks to be a bug present since time immemorial, and also seems pretty
> serious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10761) Possible regression of CASSANDRA-9201
[
https://issues.apache.org/jira/browse/CASSANDRA-10761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029046#comment-15029046
]
Sylvain Lebresne commented on CASSANDRA-10761:
--
bq. The migration thread has sucessfully updated the keyspace metadata to
include the new table metadata but it hasn't yet initialized the
{{ColumnFamilyStore}}
That's the part that feels wrong to me as it's obviously racy. We should not
add then initialize, we should initialize then add.
And as far as I can tell, it looks almost as simple as switching the 2 lines in
{{Schema::addTable}} (and {{addView}}), except for the fact that
{{Keyspace::initCf}} ultimately pulls the {{CFMetaData}} from {{Schema}}. But
that could could easily be fixed by passing said {{CFMetaData}} as argument
instead (bonus point: it even saves a map lookup).
> Possible regression of CASSANDRA-9201
> -
>
> Key: CASSANDRA-10761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10761
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.1, 3.1, 2.2.x
>
> Attachments: 10761-logs.tar.gz
>
>
> Some dtests like
> {{consistency_test.TestAccuracy.test_network_topology_strategy_each_quorum_counters}}
> are failing with the follow auth related assertion exception
> {code}
> [node6 ERROR] java.lang.AssertionError:
> org.apache.cassandra.exceptions.InvalidRequestException: unconfigured table
> roles
> at
> org.apache.cassandra.auth.CassandraRoleManager.prepare(CassandraRoleManager.java:450)
> at
> org.apache.cassandra.auth.CassandraRoleManager.setup(CassandraRoleManager.java:144)
> at
> org.apache.cassandra.service.StorageService.doAuthSetup(StorageService.java:1036)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:984)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:708)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:345)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:561)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> Caused by: org.apache.cassandra.exceptions.InvalidRequestException:
> unconfigured table roles
> at
> org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily(ThriftValidation.java:114)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:757)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:752)
> at
> org.apache.cassandra.auth.CassandraRoleManager.prepare(CassandraRoleManager.java:446)
> ... 8 more
> {code}
> This looks very similar to CASSANDRA-9201.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10776) Prepare of statements after table creation fail with unconfigured column family
[
https://issues.apache.org/jira/browse/CASSANDRA-10776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029025#comment-15029025
]
Adam Dougal commented on CASSANDRA-10776:
-
To check if IF NOT EXISTS checks only one node or not we tried running this
against a single node cluster. This caused the column family id mismatch error
to be thrown by the driver as well as being shown in the server logs.
{code}
com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried
for query failed (tried: localhost/127.0.0.1:9042
(com.datastax.driver.core.exceptions.DriverException: Host replied with server
error: java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException:
org.apache.cassandra.exceptions.ConfigurationException: Column family ID
mismatch (found 672ae1b0-9456-11e5-b539-8119a6964819; expected
672a6c80-9456-11e5-b539-8119a6964819)))
at
com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:84)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:214)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:52)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:36)
~[cassandra-driver-core-2.1.8.jar:na]
at
uk.sky.cirrus.locking.CassandraLockingMechanism.init(CassandraLockingMechanism.java:72)
~[main/:na]
at uk.sky.cirrus.locking.Lock.acquire(Lock.java:35) [main/:na]
at uk.sky.cirrus.CqlMigratorImpl.migrate(CqlMigratorImpl.java:83)
[main/:na]
at
uk.sky.cirrus.locking.LockVerificationTest.lambda$shouldManageContentionsForSchemaMigrate$0(LockVerificationTest.java:90)
[test/:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
~[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All
host(s) tried for query failed (tried: localhost/127.0.0.1:9042
(com.datastax.driver.core.exceptions.DriverException: Host replied with server
error: java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException:
org.apache.cassandra.exceptions.ConfigurationException: Column family ID
mismatch (found 672ae1b0-9456-11e5-b539-8119a6964819; expected
672a6c80-9456-11e5-b539-8119a6964819)))
at
com.datastax.driver.core.RequestHandler.reportNoMoreHosts(RequestHandler.java:217)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.RequestHandler.access$1000(RequestHandler.java:44)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.RequestHandler$SpeculativeExecution.sendRequest(RequestHandler.java:276)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.RequestHandler$SpeculativeExecution$1.run(RequestHandler.java:374)
~[cassandra-driver-core-2.1.8.jar:na]
... 3 common frames omitted
{code}
> Prepare of statements after table creation fail with unconfigured column
> family
> ---
>
> Key: CASSANDRA-10776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10776
> Project: Cassandra
> Issue Type: Bug
>Reporter: Adam Dougal
>
> Cassandra 2.1.8
> We have multiple app instances trying to create the same table using IF NOT
> EXISTS.
> We check for schema agreement via the Java Driver before and after every
> statement.
> After creating the table we then prepare statements and we sometimes get:
> {code}
> com.datastax.driver.core.exceptions.InvalidQueryException: unconfigured
> columnfamily locks
> at
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
> ~[cassandra-driver-core-2.1.8.jar:na]
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
> ~[cassandra-driver-core-2.1.8.jar:na]
> at
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:79)
> ~[cassandra-driver-core-2.1.8.jar:na]
> at
> uk.sky.cirrus.locking.CassandraLockingMechanism.init(CassandraLockingMechanism.java:69)
> ~[main/:na]
> at uk.sky.cirrus.locking.Lock.acquire(Lock.java:35) [main/:na]
> at uk.sky.cirrus.CqlMigratorImpl.migrate(CqlMigratorImpl.java:
[jira] [Updated] (CASSANDRA-9130) reduct default dtcs max_sstable_age
[ https://issues.apache.org/jira/browse/CASSANDRA-9130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-9130: Labels: dtcs (was: ) > reduct default dtcs max_sstable_age > --- > > Key: CASSANDRA-9130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9130 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Jeff Jirsa >Priority: Minor > Labels: dtcs > > Now that CASSANDRA-9056 is fixed it should be safe to reduce the default age > and increase performance correspondingly. [~jshook] suggests that two weeks > may be appropriate, or we could make it dynamic based on gcgs (since that's > the window past which we should expect repair to not introduce fragmentation > anymore). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10195) TWCS experiments and improvement proposals
[ https://issues.apache.org/jira/browse/CASSANDRA-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-10195: - Labels: dtcs (was: ) > TWCS experiments and improvement proposals > -- > > Key: CASSANDRA-10195 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10195 > Project: Cassandra > Issue Type: Improvement >Reporter: Antti Nissinen > Labels: dtcs > Fix For: 2.1.x, 2.2.x > > Attachments: 20150814_1027_compaction_hierarchy.txt, > node0_20150727_1250_time_graph.txt, node0_20150810_1017_time_graph.txt, > node0_20150812_1531_time_graph.txt, node0_20150813_0835_time_graph.txt, > node0_20150814_1054_time_graph.txt, node1_20150727_1250_time_graph.txt, > node1_20150810_1017_time_graph.txt, node1_20150812_1531_time_graph.txt, > node1_20150813_0835_time_graph.txt, node1_20150814_1054_time_graph.txt, > node2_20150727_1250_time_graph.txt, node2_20150810_1017_time_graph.txt, > node2_20150812_1531_time_graph.txt, node2_20150813_0835_time_graph.txt, > node2_20150814_1054_time_graph.txt, sstable_count_figure1.png, > sstable_count_figure2.png > > > This JIRA item describes experiments with DateTieredCompactionStartegy (DTCS) > and TimeWindowCompactionStrategy (TWCS) and proposes modifications to the > TWCS. In a test system several crashes were caused intentionally (and > unintentionally) and repair operations were executed leading to flood of > small SSTables. Target was to be able compact those files are release disk > space reserved by duplicate data. Setup is following: > - Three nodes > - DateTieredCompactionStrategy, max_sstable_age_days = 5 > Cassandra 2.1.2 > The setup and data format has been documented in detailed here > https://issues.apache.org/jira/browse/CASSANDRA-9644. > The test was started by dumping few days worth of data to the database for > 100 000 signals. Time graphs of SStables from different nodes indicates that > the DTCS has been working as expected and SStables are nicely ordered in time > wise. > See files: > node0_20150727_1250_time_graph.txt > node1_20150727_1250_time_graph.txt > node2_20150727_1250_time_graph.txt > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens OwnsHost ID > Rack > UN 139.66.43.170 188.87 GB 256 ? > dfc29863-c935-4909-9d7f-c59a47eda03d rack1 > UN 139.66.43.169 198.37 GB 256 ? > 12e7628b-7f05-48f6-b7e4-35a82010021a rack1 > UN 139.66.43.168 191.88 GB 256 ? > 26088392-f803-4d59-9073-c75f857fb332 rack1 > All nodes crashed due to power failure (know beforehand) and repair > operations were started for each node one at the time. Below is the behavior > of SSTable count on different nodes. New data was dumped simultaneously with > repair operation. > SEE FIGURE: sstable_count_figure1.png > Vertical lines indicate following events. > 1) Cluster was down due to power shutdown and was restarted. At the first > vertical line the repair operation (nodetool repair -pr) was started for the > first node > 2) Repair for the second repair operation was started after the first node > was successfully repaired. > 3) Repair for the third repair operation was started > 4) Third repair operation was finished > 5) One of the nodes crashed (unknown reason in OS level) > 6) Repair operation (nodetool repair -pr) was started for the first node > 7) Repair operation for the second node was started > 8) Repair operation for the third node was started > 9) Repair operations finished > These repair operations are leading to huge amount of small SSTables covering > the whole time span of the data. The compaction horizon of DTCS was limited > to 5 days (max_sstable_age_days) due to the size of the SStables on the disc. > Therefore, small SStables won't be compacted. Below are the time graphs from > SSTables after the second round of repairs. > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens OwnsHost ID > Rack > UN xx.xx.xx.170 663.61 GB 256 ? > dfc29863-c935-4909-9d7f-c59a47eda03d rack1 > UN xx.xx.xx.169 763.52 GB 256 ? > 12e7628b-7f05-48f6-b7e4-35a82010021a rack1 > UN xx.xx.xx.168 651.59 GB 256 ? > 26088392-f803-4d59-9073-c75f857fb332 rack1 > See files: > node0_20150810_1017_time_graph.txt > node1_20150810_1017_time_graph.txt > node2_20150810_1017_time_graph.txt > To get rid of the SStables the TimeWindowCompactionStrategy was taken into > use. Window size was set to 5 days. Cassandra version was updated to 2.1.8. > Below figure shows the behavior of SStable count. TWCS was taken into use > 10.8.2015 at 13:10. The maximum amount of files to be compacted in one task > was li
[jira] [Updated] (CASSANDRA-9013) Add new option making DTCS unify larger time windows sooner
[ https://issues.apache.org/jira/browse/CASSANDRA-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-9013: Labels: dtcs (was: ) > Add new option making DTCS unify larger time windows sooner > --- > > Key: CASSANDRA-9013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9013 > Project: Cassandra > Issue Type: Improvement >Reporter: Björn Hegerfors >Assignee: Björn Hegerfors >Priority: Minor > Labels: dtcs > Attachments: cassandra-2.0-CASSANDRA-9013.txt > > > In my very long post on CASSANDRA-6602, I mentioned a more aggressive > windowing strategy, which looks for opportunities to compact into larger > SSTables sooner. The original approach was that when we have min_threshold > windows of the same size and another one of the same size appears next to > them, those windows (not including the newest addition) merge. This new > approach doesn't wait for a (min_threshold+1)th one. As soon as min_threshold > windows of one size are created, they merge at once. The only exception is > the "incoming window", which stays outside of merging with other windows > until it is no longer the incoming window. > This does mean that occasionally more than min_threshold SSTables, not all of > similar size get compacted, intentionally. For example, let's say > min_threshold is 4, then if we have 3 windows size 16, 3 windows size 4 and > just get a 4th size 1 window that isn't the incoming window, we immediately > merge all of those into a size 64 window. Typically we expect one SSTable to > be in each window with a file size corresponding to the window size in some > unit of measure. So we merge roughly 10 SSTables in that scenario. > These bigger compactions happen rarely, about as often as a similar thing > happens in STCS (on occasion the number of SSTables gets very small). This > tweak to DTCS is meant to mimic that behavior in STCS. It has been observed > that DTCS typically has 50% to 100% more SSTables than STCS, so this is a way > to counter that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10742) Real world DateTieredCompaction tests
[ https://issues.apache.org/jira/browse/CASSANDRA-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-10742: - Labels: dtcs (was: ) > Real world DateTieredCompaction tests > - > > Key: CASSANDRA-10742 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10742 > Project: Cassandra > Issue Type: Test >Reporter: Marcus Eriksson > Labels: dtcs > > So, to be able to actually evaluate DTCS (or TWCS) we need stress profiles > that are similar to something that could be found in real production systems. > We should then run these profiles for _weeks_, and do regular operational > tasks on the cluster - like bootstrap, decom, repair etc. > [~jjirsa] [~jshook] (or anyone): could you describe any write/read patterns > you have seen people use with DTCS in production? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10280) Make DTCS work well with old data
[ https://issues.apache.org/jira/browse/CASSANDRA-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-10280: - Labels: docs-impacting dtcs (was: docs-impacting) > Make DTCS work well with old data > - > > Key: CASSANDRA-10280 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10280 > Project: Cassandra > Issue Type: Sub-task >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: docs-impacting, dtcs > Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1 > > > Operational tasks become incredibly expensive if you keep around a long > timespan of data with DTCS - with default settings and 1 year of data, the > oldest window covers about 180 days. Bootstrapping a node with vnodes with > this data layout will force cassandra to compact very many sstables in this > window. > We should probably put a cap on how big the biggest windows can get. We could > probably default this to something sane based on max_sstable_age (ie, say we > can reasonably handle 1000 sstables per node, then we can calculate how big > the windows should be to allow that) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10761) Possible regression of CASSANDRA-9201
[
https://issues.apache.org/jira/browse/CASSANDRA-10761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028964#comment-15028964
]
Sam Tunnicliffe commented on CASSANDRA-10761:
-
Unfortunately, it seems that the startup is still not race-free, the good news
though is that dtest CI runs are proving useful in catching them.
{code}
[node3 ERROR] java.lang.IllegalArgumentException: Unknown CF
5bc52802-de25-35ed-aeab-188eecebb090
at
org.apache.cassandra.db.Keyspace.getColumnFamilyStore(Keyspace.java:206)
at
org.apache.cassandra.db.Keyspace.getColumnFamilyStore(Keyspace.java:199)
at
org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:161)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepareRestrictions(SelectStatement.java:817)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:764)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:752)
at
org.apache.cassandra.auth.CassandraRoleManager.prepare(CassandraRoleManager.java:446)
at
org.apache.cassandra.auth.CassandraRoleManager.setup(CassandraRoleManager.java:144)
at
org.apache.cassandra.service.StorageService.doAuthSetup(StorageService.java:1035)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:983)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:706)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:577)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:345)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:561)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
{code}
as seen in [this dtest
run|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10761-3.0-dtest/lastCompletedBuild/testReport/paging_test/TestPagingData/test_paging_using_secondary_indexes/]
highlights another race condition (I ran this same test 50 times locally
without error). The migration thread has sucessfully updated the keyspace
metadata to include the new table metadata but it hasn't yet initialized the
{{ColumnFamilyStore}} (so in {{Schema::addTable}} the call to {{update}} has
happened/is happening but not the call to {{initCf}}. In the main thread, this
causes the test of the table metadata in {{maybeAddOrUpdateKeyspace}} to pass
and control returns to {{doAuthSetup}}, which in turn goes onto initialize the
role manager, leading to the exception over the missing CFS.
One way to deal with this could be to block until we can be sure that the
keyspace is not only set up in schema, but that its tables are actually usable.
We only ever see this affecting {{system_auth}} because we attempt to use it
very early during startup, but in theory {{system_traces}} and
{{system_distributed}} are also susceptible to this race.
I've pushed additional commits to the branches linked earlier to make that
additional check, but for now only for {{system_auth}}. [~slebresne], any
better ideas?
> Possible regression of CASSANDRA-9201
> -
>
> Key: CASSANDRA-10761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10761
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Philip Thompson
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.1, 3.1, 2.2.x
>
> Attachments: 10761-logs.tar.gz
>
>
> Some dtests like
> {{consistency_test.TestAccuracy.test_network_topology_strategy_each_quorum_counters}}
> are failing with the follow auth related assertion exception
> {code}
> [node6 ERROR] java.lang.AssertionError:
> org.apache.cassandra.exceptions.InvalidRequestException: unconfigured table
> roles
> at
> org.apache.cassandra.auth.CassandraRoleManager.prepare(CassandraRoleManager.java:450)
> at
> org.apache.cassandra.auth.CassandraRoleManager.setup(CassandraRoleManager.java:144)
> at
> org.apache.cassandra.service.StorageService.doAuthSetup(StorageService.java:1036)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:984)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:708)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:345)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:561)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> Caused by: org.apache.cassandra.exceptions.InvalidRequestException:
> unconfi
[jira] [Commented] (CASSANDRA-10729) SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT return wrong results
[
https://issues.apache.org/jira/browse/CASSANDRA-10729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028954#comment-15028954
]
Sylvain Lebresne commented on CASSANDRA-10729:
--
+1
> SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT
> return wrong results
> --
>
> Key: CASSANDRA-10729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10729
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0.1, 3.1, 3.2
>
> Attachments: 10729-3.0.txt
>
>
> If we execute a request with paging turned off, an IN restriction on the
> partition key, ORDER BY and LIMIT the result returned are not the expected
> ones.
> The following test can be used to reproduce the problem.
> {code}
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, v text,
> PRIMARY KEY ((pk1, pk2), c) )");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 2, "A");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 2,
> 1, "B");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 3,
> 3, "C");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 4, "D");
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c; ", 1, 1, 2),
>row("B"),
>row("A"),
>row("D"));
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c LIMIT 2; ", 1, 1, 2),
>row("B"),
>row("A"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10280) Make DTCS work well with old data
[
https://issues.apache.org/jira/browse/CASSANDRA-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028927#comment-15028927
]
Paulo Motta commented on CASSANDRA-10280:
-
Just for the record {{max_window_size_seconds}} property broke some trivial
cqlsh completion tests, which is fixed on CASSANDRA-10753.
> Make DTCS work well with old data
> -
>
> Key: CASSANDRA-10280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10280
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Labels: docs-impacting
> Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1
>
>
> Operational tasks become incredibly expensive if you keep around a long
> timespan of data with DTCS - with default settings and 1 year of data, the
> oldest window covers about 180 days. Bootstrapping a node with vnodes with
> this data layout will force cassandra to compact very many sstables in this
> window.
> We should probably put a cap on how big the biggest windows can get. We could
> probably default this to something sane based on max_sstable_age (ie, say we
> can reasonably handle 1000 sstables per node, then we can calculate how big
> the windows should be to allow that)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10753) Fix completion problems breaking clqshlib tests
[
https://issues.apache.org/jira/browse/CASSANDRA-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028923#comment-15028923
]
Paulo Motta commented on CASSANDRA-10753:
-
Looks good. Minor nits:
* In {{test_timestamp_output}} since the {{TZ}} property is ignored I guess we
can just remove the second equals statement which is the same as the first.
What do you think?
* The {{max_window_size_seconds}} problem is also affecting 2.2, could you
provide a 2.2 patch? (It's not on jenkins but since we'll still maintain 2.2
for some time, I guess we should fix it).
After that should be good to go. Thanks!
> Fix completion problems breaking clqshlib tests
> ---
>
> Key: CASSANDRA-10753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10753
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.x
>
>
> The recent changes in the python driver APIs have caused some completion
> problems as indicated by 2 of these failing tests:
> http://cassci.datastax.com/job/trunk_cqlshlib/579/testReport/
> The third failing test, {{test_timestamp_output}}, has been failing for some
> time due to uncertainty on what to do regarding timezone conversion but it
> too can be changed to reflect the fact that we convert the timestamp to UTC.
> Finally, {{max_window_size_seconds}} was recently added to the compaction
> properties and this caused 2 more tests to fail. It cannot be seen on Jenkins
> because of the relative import problem introduced by CASSANDRA-9304.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
cassandra git commit: Merge from 3.1
Repository: cassandra
Updated Branches:
refs/heads/trunk fa92ae66d -> 4901af68a
Merge from 3.1
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4901af68
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4901af68
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4901af68
Branch: refs/heads/trunk
Commit: 4901af68aa12c9a482c5e8c4ef7e7d0fb23a5afe
Parents: fa92ae6
Author: Sylvain Lebresne
Authored: Thu Nov 26 15:45:31 2015 +0100
Committer: Sylvain Lebresne
Committed: Thu Nov 26 15:45:31 2015 +0100
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4901af68/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 37e60cb..41609cf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -28,6 +28,7 @@ Merged from 2.2:
* (Hadoop) fix splits calculation (CASSANDRA-10640)
* (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058)
Merged from 2.1:
+ * Force encoding when computing statement ids (CASSANDRA-10755)
* Properly reject counters as map keys (CASSANDRA-10760)
* Fix the sstable-needs-cleanup check (CASSANDRA-10740)
* (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4901af68/src/java/org/apache/cassandra/utils/MD5Digest.java
--
diff --git a/src/java/org/apache/cassandra/utils/MD5Digest.java
b/src/java/org/apache/cassandra/utils/MD5Digest.java
index 3f46458..2dc57de 100644
--- a/src/java/org/apache/cassandra/utils/MD5Digest.java
+++ b/src/java/org/apache/cassandra/utils/MD5Digest.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.utils;
+import java.io.UnsupportedEncodingException;
import java.util.Arrays;
/**
@@ -50,7 +51,14 @@ public class MD5Digest
public static MD5Digest compute(String toHash)
{
-return compute(toHash.getBytes());
+try
+{
+return compute(toHash.getBytes("UTF-8"));
+}
+catch (UnsupportedEncodingException e)
+{
+throw new RuntimeException(e.getMessage());
+}
}
@Override
[1/3] cassandra git commit: Force encoding charset when computed prepared statement IDs
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 64a3bfd29 -> f4dab0f9b
Force encoding charset when computed prepared statement IDs
patch by Stefan Podkowinski; reviewed by slebresne for CASSANDRA-10755
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5b9f710
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5b9f710
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5b9f710
Branch: refs/heads/cassandra-3.0
Commit: b5b9f7106d66eda6e41cea292bc569886b701448
Parents: cdf0485
Author: Stefan Podkowinski
Authored: Mon Nov 23 17:12:35 2015 +0100
Committer: Sylvain Lebresne
Committed: Thu Nov 26 11:02:30 2015 +0100
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7978a56..ee0bc61 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.12
+ * Force encoding when computing statement ids (CASSANDRA-10755)
* Properly reject counters as map keys (CASSANDRA-10760)
* Fix the sstable-needs-cleanup check (CASSANDRA-10740)
* (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/src/java/org/apache/cassandra/utils/MD5Digest.java
--
diff --git a/src/java/org/apache/cassandra/utils/MD5Digest.java
b/src/java/org/apache/cassandra/utils/MD5Digest.java
index 3f46458..2dc57de 100644
--- a/src/java/org/apache/cassandra/utils/MD5Digest.java
+++ b/src/java/org/apache/cassandra/utils/MD5Digest.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.utils;
+import java.io.UnsupportedEncodingException;
import java.util.Arrays;
/**
@@ -50,7 +51,14 @@ public class MD5Digest
public static MD5Digest compute(String toHash)
{
-return compute(toHash.getBytes());
+try
+{
+return compute(toHash.getBytes("UTF-8"));
+}
+catch (UnsupportedEncodingException e)
+{
+throw new RuntimeException(e.getMessage());
+}
}
@Override
[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f4dab0f9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f4dab0f9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f4dab0f9 Branch: refs/heads/cassandra-3.0 Commit: f4dab0f9b3a037c952aaa71219987eb4f44535e5 Parents: 64a3bfd e4f3dba Author: Sylvain Lebresne Authored: Thu Nov 26 15:44:18 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:44:18 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f4dab0f9/CHANGES.txt -- diff --cc CHANGES.txt index 04cda25,d31645a..eab04fb --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -14,7 -4,16 +14,8 @@@ Merged from 2.2 * Fix SimpleDateType type compatibility (CASSANDRA-10027) * (Hadoop) fix splits calculation (CASSANDRA-10640) * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) - * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) - * Use most up-to-date version of schema for system tables (CASSANDRA-10652) - * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) - * Expose phi values from failure detector via JMX and tweak debug - and trace logging (CASSANDRA-9526) - * Fix RangeNamesQueryPager (CASSANDRA-10509) - * Deprecate Pig support (CASSANDRA-10542) - * Reduce contention getting instances of CompositeType (CASSANDRA-10433) Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
[3/4] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f4dab0f9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f4dab0f9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f4dab0f9 Branch: refs/heads/cassandra-3.1 Commit: f4dab0f9b3a037c952aaa71219987eb4f44535e5 Parents: 64a3bfd e4f3dba Author: Sylvain Lebresne Authored: Thu Nov 26 15:44:18 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:44:18 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f4dab0f9/CHANGES.txt -- diff --cc CHANGES.txt index 04cda25,d31645a..eab04fb --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -14,7 -4,16 +14,8 @@@ Merged from 2.2 * Fix SimpleDateType type compatibility (CASSANDRA-10027) * (Hadoop) fix splits calculation (CASSANDRA-10640) * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) - * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) - * Use most up-to-date version of schema for system tables (CASSANDRA-10652) - * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) - * Expose phi values from failure detector via JMX and tweak debug - and trace logging (CASSANDRA-9526) - * Fix RangeNamesQueryPager (CASSANDRA-10509) - * Deprecate Pig support (CASSANDRA-10542) - * Reduce contention getting instances of CompositeType (CASSANDRA-10433) Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
[2/3] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4f3dbac Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4f3dbac Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4f3dbac Branch: refs/heads/cassandra-3.0 Commit: e4f3dbac02471cf69d4e525fc24cc288de32ed73 Parents: 8bfdd65 b5b9f71 Author: Sylvain Lebresne Authored: Thu Nov 26 15:43:55 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:43:55 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4f3dbac/CHANGES.txt -- diff --cc CHANGES.txt index 237c251,ee0bc61..d31645a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,18 -1,5 +1,19 @@@ -2.1.12 +2.2.4 + * Fix JSON update with prepared statements (CASSANDRA-10631) + * Don't do anticompaction after subrange repair (CASSANDRA-10422) + * Fix SimpleDateType type compatibility (CASSANDRA-10027) + * (Hadoop) fix splits calculation (CASSANDRA-10640) + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) + * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) + * Use most up-to-date version of schema for system tables (CASSANDRA-10652) + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) + * Expose phi values from failure detector via JMX and tweak debug + and trace logging (CASSANDRA-9526) + * Fix RangeNamesQueryPager (CASSANDRA-10509) + * Deprecate Pig support (CASSANDRA-10542) + * Reduce contention getting instances of CompositeType (CASSANDRA-10433) +Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
[1/4] cassandra git commit: Force encoding charset when computed prepared statement IDs
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.1 b7ead2b33 -> 0e5aa51d1
Force encoding charset when computed prepared statement IDs
patch by Stefan Podkowinski; reviewed by slebresne for CASSANDRA-10755
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5b9f710
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5b9f710
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5b9f710
Branch: refs/heads/cassandra-3.1
Commit: b5b9f7106d66eda6e41cea292bc569886b701448
Parents: cdf0485
Author: Stefan Podkowinski
Authored: Mon Nov 23 17:12:35 2015 +0100
Committer: Sylvain Lebresne
Committed: Thu Nov 26 11:02:30 2015 +0100
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7978a56..ee0bc61 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.12
+ * Force encoding when computing statement ids (CASSANDRA-10755)
* Properly reject counters as map keys (CASSANDRA-10760)
* Fix the sstable-needs-cleanup check (CASSANDRA-10740)
* (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/src/java/org/apache/cassandra/utils/MD5Digest.java
--
diff --git a/src/java/org/apache/cassandra/utils/MD5Digest.java
b/src/java/org/apache/cassandra/utils/MD5Digest.java
index 3f46458..2dc57de 100644
--- a/src/java/org/apache/cassandra/utils/MD5Digest.java
+++ b/src/java/org/apache/cassandra/utils/MD5Digest.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.utils;
+import java.io.UnsupportedEncodingException;
import java.util.Arrays;
/**
@@ -50,7 +51,14 @@ public class MD5Digest
public static MD5Digest compute(String toHash)
{
-return compute(toHash.getBytes());
+try
+{
+return compute(toHash.getBytes("UTF-8"));
+}
+catch (UnsupportedEncodingException e)
+{
+throw new RuntimeException(e.getMessage());
+}
}
@Override
[4/4] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.1
Merge branch 'cassandra-3.0' into cassandra-3.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0e5aa51d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0e5aa51d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0e5aa51d Branch: refs/heads/cassandra-3.1 Commit: 0e5aa51d1222b5d4434b6c79e41931332e58a7f4 Parents: b7ead2b f4dab0f Author: Sylvain Lebresne Authored: Thu Nov 26 15:44:44 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:44:44 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0e5aa51d/CHANGES.txt --
[2/4] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4f3dbac Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4f3dbac Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4f3dbac Branch: refs/heads/cassandra-3.1 Commit: e4f3dbac02471cf69d4e525fc24cc288de32ed73 Parents: 8bfdd65 b5b9f71 Author: Sylvain Lebresne Authored: Thu Nov 26 15:43:55 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:43:55 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4f3dbac/CHANGES.txt -- diff --cc CHANGES.txt index 237c251,ee0bc61..d31645a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,18 -1,5 +1,19 @@@ -2.1.12 +2.2.4 + * Fix JSON update with prepared statements (CASSANDRA-10631) + * Don't do anticompaction after subrange repair (CASSANDRA-10422) + * Fix SimpleDateType type compatibility (CASSANDRA-10027) + * (Hadoop) fix splits calculation (CASSANDRA-10640) + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) + * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) + * Use most up-to-date version of schema for system tables (CASSANDRA-10652) + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) + * Expose phi values from failure detector via JMX and tweak debug + and trace logging (CASSANDRA-9526) + * Fix RangeNamesQueryPager (CASSANDRA-10509) + * Deprecate Pig support (CASSANDRA-10542) + * Reduce contention getting instances of CompositeType (CASSANDRA-10433) +Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
[1/2] cassandra git commit: Force encoding charset when computed prepared statement IDs
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 8bfdd65c0 -> e4f3dbac0
Force encoding charset when computed prepared statement IDs
patch by Stefan Podkowinski; reviewed by slebresne for CASSANDRA-10755
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5b9f710
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5b9f710
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5b9f710
Branch: refs/heads/cassandra-2.2
Commit: b5b9f7106d66eda6e41cea292bc569886b701448
Parents: cdf0485
Author: Stefan Podkowinski
Authored: Mon Nov 23 17:12:35 2015 +0100
Committer: Sylvain Lebresne
Committed: Thu Nov 26 11:02:30 2015 +0100
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7978a56..ee0bc61 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.12
+ * Force encoding when computing statement ids (CASSANDRA-10755)
* Properly reject counters as map keys (CASSANDRA-10760)
* Fix the sstable-needs-cleanup check (CASSANDRA-10740)
* (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/src/java/org/apache/cassandra/utils/MD5Digest.java
--
diff --git a/src/java/org/apache/cassandra/utils/MD5Digest.java
b/src/java/org/apache/cassandra/utils/MD5Digest.java
index 3f46458..2dc57de 100644
--- a/src/java/org/apache/cassandra/utils/MD5Digest.java
+++ b/src/java/org/apache/cassandra/utils/MD5Digest.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.utils;
+import java.io.UnsupportedEncodingException;
import java.util.Arrays;
/**
@@ -50,7 +51,14 @@ public class MD5Digest
public static MD5Digest compute(String toHash)
{
-return compute(toHash.getBytes());
+try
+{
+return compute(toHash.getBytes("UTF-8"));
+}
+catch (UnsupportedEncodingException e)
+{
+throw new RuntimeException(e.getMessage());
+}
}
@Override
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4f3dbac Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4f3dbac Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4f3dbac Branch: refs/heads/cassandra-2.2 Commit: e4f3dbac02471cf69d4e525fc24cc288de32ed73 Parents: 8bfdd65 b5b9f71 Author: Sylvain Lebresne Authored: Thu Nov 26 15:43:55 2015 +0100 Committer: Sylvain Lebresne Committed: Thu Nov 26 15:43:55 2015 +0100 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4f3dbac/CHANGES.txt -- diff --cc CHANGES.txt index 237c251,ee0bc61..d31645a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,18 -1,5 +1,19 @@@ -2.1.12 +2.2.4 + * Fix JSON update with prepared statements (CASSANDRA-10631) + * Don't do anticompaction after subrange repair (CASSANDRA-10422) + * Fix SimpleDateType type compatibility (CASSANDRA-10027) + * (Hadoop) fix splits calculation (CASSANDRA-10640) + * (Hadoop) ensure that Cluster instances are always closed (CASSANDRA-10058) + * (cqlsh) show partial trace if incomplete after max_trace_wait (CASSANDRA-7645) + * Use most up-to-date version of schema for system tables (CASSANDRA-10652) + * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581,10628) + * Expose phi values from failure detector via JMX and tweak debug + and trace logging (CASSANDRA-9526) + * Fix RangeNamesQueryPager (CASSANDRA-10509) + * Deprecate Pig support (CASSANDRA-10542) + * Reduce contention getting instances of CompositeType (CASSANDRA-10433) +Merged from 2.1: + * Force encoding when computing statement ids (CASSANDRA-10755) * Properly reject counters as map keys (CASSANDRA-10760) * Fix the sstable-needs-cleanup check (CASSANDRA-10740) * (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
cassandra git commit: Force encoding charset when computed prepared statement IDs
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 cdf0485b2 -> b5b9f7106
Force encoding charset when computed prepared statement IDs
patch by Stefan Podkowinski; reviewed by slebresne for CASSANDRA-10755
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5b9f710
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5b9f710
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5b9f710
Branch: refs/heads/cassandra-2.1
Commit: b5b9f7106d66eda6e41cea292bc569886b701448
Parents: cdf0485
Author: Stefan Podkowinski
Authored: Mon Nov 23 17:12:35 2015 +0100
Committer: Sylvain Lebresne
Committed: Thu Nov 26 11:02:30 2015 +0100
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/utils/MD5Digest.java | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7978a56..ee0bc61 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.12
+ * Force encoding when computing statement ids (CASSANDRA-10755)
* Properly reject counters as map keys (CASSANDRA-10760)
* Fix the sstable-needs-cleanup check (CASSANDRA-10740)
* (cqlsh) Print column names before COPY operation (CASSANDRA-8935)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5b9f710/src/java/org/apache/cassandra/utils/MD5Digest.java
--
diff --git a/src/java/org/apache/cassandra/utils/MD5Digest.java
b/src/java/org/apache/cassandra/utils/MD5Digest.java
index 3f46458..2dc57de 100644
--- a/src/java/org/apache/cassandra/utils/MD5Digest.java
+++ b/src/java/org/apache/cassandra/utils/MD5Digest.java
@@ -17,6 +17,7 @@
*/
package org.apache.cassandra.utils;
+import java.io.UnsupportedEncodingException;
import java.util.Arrays;
/**
@@ -50,7 +51,14 @@ public class MD5Digest
public static MD5Digest compute(String toHash)
{
-return compute(toHash.getBytes());
+try
+{
+return compute(toHash.getBytes("UTF-8"));
+}
+catch (UnsupportedEncodingException e)
+{
+throw new RuntimeException(e.getMessage());
+}
}
@Override
[jira] [Commented] (CASSANDRA-10729) SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT return wrong results
[
https://issues.apache.org/jira/browse/CASSANDRA-10729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028911#comment-15028911
]
Benjamin Lerer commented on CASSANDRA-10729:
I renamed {{getUserLimit}} to {{getLimit}}, moved the comment and made
{{getDataLimit}} private.
The new patch can be found
[here|https://github.com/apache/cassandra/compare/trunk...blerer:10729-3.0]
> SELECT statement with IN restrictions on partition key + ORDER BY + LIMIT
> return wrong results
> --
>
> Key: CASSANDRA-10729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10729
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0.1, 3.1, 3.2
>
> Attachments: 10729-3.0.txt
>
>
> If we execute a request with paging turned off, an IN restriction on the
> partition key, ORDER BY and LIMIT the result returned are not the expected
> ones.
> The following test can be used to reproduce the problem.
> {code}
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, v text,
> PRIMARY KEY ((pk1, pk2), c) )");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 2, "A");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 2,
> 1, "B");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 3,
> 3, "C");
> execute("INSERT INTO %s (pk1, pk2, c, v) VALUES (?, ?, ?, ?)", 1, 1,
> 4, "D");
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c; ", 1, 1, 2),
>row("B"),
>row("A"),
>row("D"));
> assertRows(execute("SELECT v as c FROM %s where pk1 = ? AND pk2 IN
> (?, ?) ORDER BY c LIMIT 2; ", 1, 1, 2),
>row("B"),
>row("A"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9991) Implement efficient btree removal
[ https://issues.apache.org/jira/browse/CASSANDRA-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028899#comment-15028899 ] Piotr Jastrzebski commented on CASSANDRA-9991: -- Ok thanks. I will try to make it more efficient. > Implement efficient btree removal > - > > Key: CASSANDRA-9991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9991 > Project: Cassandra > Issue Type: Sub-task >Reporter: Benedict > Labels: patch > Fix For: 3.x > > Attachments: trunk-9991-v3.txt, trunk-9991.txt, trunk-9991.txt-v2 > > > Currently removal is implemented as a reconstruction by filtering and > iterator over the original btree. This could be much more efficient, editing > just the necessary nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9991) Implement efficient btree removal
[
https://issues.apache.org/jira/browse/CASSANDRA-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028883#comment-15028883
]
Branimir Lambov commented on CASSANDRA-9991:
Not that cheap, walking the tree will always be expensive to some extent. It
may be better to go with something closer to the original version then, where
remove finds the leaf and passes indices to {{removeFromLeaf}} and {{swap}}
(which isn't much more code as {{isLeaf}} can disappear), but I will leave that
choice to you. The current code LGTM as well.
[{{BTree.swap}}|https://github.com/apache/cassandra/compare/trunk...blambov:haaawk/9991#diff-4b911b7d0959c6219175e2349968f3cdR330]
should use the naming of {{replaceInSitu}} and contain the same warning.
[Testall|http://cassci.datastax.com/job/blambov-haaawk-9991-testall/] looks
same as trunk,
[dtest|http://cassci.datastax.com/job/blambov-haaawk-9991-dtest/] is still
running.
> Implement efficient btree removal
> -
>
> Key: CASSANDRA-9991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9991
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Benedict
> Labels: patch
> Fix For: 3.x
>
> Attachments: trunk-9991-v3.txt, trunk-9991.txt, trunk-9991.txt-v2
>
>
> Currently removal is implemented as a reconstruction by filtering and
> iterator over the original btree. This could be much more efficient, editing
> just the necessary nodes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10776) Prepare of statements after table creation fail with unconfigured column family
Adam Dougal created CASSANDRA-10776:
---
Summary: Prepare of statements after table creation fail with
unconfigured column family
Key: CASSANDRA-10776
URL: https://issues.apache.org/jira/browse/CASSANDRA-10776
Project: Cassandra
Issue Type: Bug
Reporter: Adam Dougal
Cassandra 2.1.8
We have multiple app instances trying to create the same table using IF NOT
EXISTS.
We check for schema agreement via the Java Driver before and after every
statement.
After creating the table we then prepare statements and we sometimes get:
{code}
com.datastax.driver.core.exceptions.InvalidQueryException: unconfigured
columnfamily locks
at
com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
~[cassandra-driver-core-2.1.8.jar:na]
at
com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:79)
~[cassandra-driver-core-2.1.8.jar:na]
at
uk.sky.cirrus.locking.CassandraLockingMechanism.init(CassandraLockingMechanism.java:69)
~[main/:na]
at uk.sky.cirrus.locking.Lock.acquire(Lock.java:35) [main/:na]
at uk.sky.cirrus.CqlMigratorImpl.migrate(CqlMigratorImpl.java:83)
[main/:na]
at
uk.sky.cirrus.locking.LockVerificationTest.lambda$shouldManageContentionsForSchemaMigrate$0(LockVerificationTest.java:90)
[test/:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
~[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
{code}
Looking at the server logs we get:
{code}
ava.lang.RuntimeException:
org.apache.cassandra.exceptions.ConfigurationException: Column family ID
mismatch (found 90bbb372-9446-11e5-b1ca-8119a6964819; expected
90b87f20-9446-11e5-b1ca-8119a6964819)
at org.apache.cassandra.config.CFMetaData.reload(CFMetaData.java:1145)
~[main/:na]
at
org.apache.cassandra.db.DefsTables.updateColumnFamily(DefsTables.java:422)
~[main/:na]
at
org.apache.cassandra.db.DefsTables.mergeColumnFamilies(DefsTables.java:295)
~[main/:na]
at
org.apache.cassandra.db.DefsTables.mergeSchemaInternal(DefsTables.java:194)
~[main/:na]
at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:166)
~[main/:na]
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:49)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
{code}
We found this issue which is marked as resolved:
https://issues.apache.org/jira/browse/CASSANDRA-8387
Does the IF NOT EXISTS just check the local node?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9279) Gossip (and mutations) lock up on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-9279:
---
Component/s: Lifecycle
Coordination
> Gossip (and mutations) lock up on startup
> -
>
> Key: CASSANDRA-9279
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9279
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination, Lifecycle
>Reporter: Sebastian Estevez
>Assignee: Paulo Motta
> Attachments: Screen Shot 2015-04-30 at 4.41.57 PM.png
>
>
> Cluster running 2.0.14.352 on EC2 - c3.4xl's
> 2 nodes out of 8 exhibited the following behavior
> When starting up the node we noticed it was gray in OpsCenter. Other
> monitoring tool showed it as up.
> Turned out gossip tasks were piling up and we could see the following in the
> system.log:
> {code}
> WARN [GossipTasks:1] 2015-04-30 20:22:29,512 Gossiper.java (line 671) Gossip
> stage has 4270 pending tasks; skipping status check (no nodes will be marked
> down)
> WARN [GossipTasks:1] 2015-04-30 20:22:30,612 Gossiper.java (line 671) Gossip
> stage has 4272 pending tasks; skipping status check (no nodes will be marked
> down)
> WARN [GossipTasks:1] 2015-04-30 20:22:31,713 Gossiper.java (line 671) Gossip
> stage has 4273 pending tasks; skipping status check (no nodes will be marked
> down)
> ...
> {code}
> and tpstats shows blocked tasks--gossip and mutations:
> {code}
> GossipStage 1 3904 29384 0
> 0
> {code}
> the CPU's are inactive (See attachment)
> and dstat output:
> {code}
> You did not select any stats, using -cdngy by default.
> total-cpu-usage -dsk/total- -net/total- ---paging-- ---system--
> usr sys idl wai hiq siq| read writ| recv send| in out | int csw
> 2 0 97 0 0 0|1324k 1381k| 0 0 | 0 0 |6252 5548
> 0 0 100 0 0 0| 064k| 42k 1017k| 0 0 |3075 2537
> 0 0 99 0 0 0| 0 8192B| 39k 794k| 0 0 |6999 7039
> 0 0 100 0 0 0| 0 0 | 39k 759k| 0 0 |3067 2726
> 0 0 99 0 0 0| 0 184k| 48k 1086k| 0 0 |4829 4178
> 0 0 99 0 0 0| 0 8192B| 34k 802k| 0 0 |1671 1240
> 0 0 100 0 0 0| 0 8192B| 48k 1067k| 0 0 |1878 1193
> {code}
> I managed to grab a thread dump:
> https://gist.githubusercontent.com/anonymous/3b7b4698c32032603493/raw/read.md
> and dmesg:
> https://gist.githubusercontent.com/anonymous/5982b15337c9afbd5d49/raw/f3c2e4411b9d59e90f4615d93c7c1ad25922e170/read.md
> Restarting the node solved the issue (it came up normally), we don't know
> what is causing it but apparently (per the thread dump) gossip threads are
> blocked writing the system keyspace and the writes waiting on the commitlog.
> Gossip:
> {code}
> "GossipStage:1" daemon prio=10 tid=0x7ffa23471800 nid=0xa13fa waiting on
> condition [0x7ff9cbe26000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005d3f50960> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:351)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:336)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:211)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:709)
> at
> org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:208)
> at
> org.apache.cassandra.db.SystemKeyspace.updatePeerInfo(SystemKeyspace.java:379)
> - locked <0x0005d3f41ed8> (a java.lang.Class for
> org.apache.cassandra.db.SystemKeyspace)
> at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:1414)
> at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1524)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1350)
> at
> org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1083)
> at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1065)
>
[jira] [Updated] (CASSANDRA-7450) Make repair -pr work within a datacenter
[ https://issues.apache.org/jira/browse/CASSANDRA-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-7450: --- Component/s: Streaming and Messaging > Make repair -pr work within a datacenter > > > Key: CASSANDRA-7450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7450 > Project: Cassandra > Issue Type: Improvement > Components: Streaming and Messaging >Reporter: Sylvain Lebresne >Assignee: Paulo Motta > Labels: bootcamp, repair > Fix For: 2.1.1 > > Attachments: 2.1-CASSANDRA-7450-v1.txt, 2.1-CASSANDRA-7450-v2.txt, > 7450-2.1-v3.txt > > > As was noticed in CASSANDRA-7317, using '-pr' alongside '-local' for repair > doesn't really work properly, and disabling the combination was definitively > the right short time fix. However, the main goal of '-pr' is to make it easy > to repair a full cluster without doing any duplication of work. Doing the > same only within a data-center is obviously desirable. > I think a reasonably simple solution would be modify the behavior of '-pr' > when it's limited to only one DC. If applied to nodeX in dcY, instead of > repairing only the "primary" range of nodeX for the whole ring, we'll repair > that range but also all ranges that are "primary" for a node not in dcY and > for which nodeX is the first node of dcY found in ring order. Basically we'll > ensure that running 'repair -local -pr' on every nodes of a given DC will > repair all ranges for the nodes of that DC without repairing the same range > twice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10004) Allow changing default encoding on cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10004: Component/s: Tools > Allow changing default encoding on cqlsh > > > Key: CASSANDRA-10004 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10004 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Minor > Labels: cqlsh > Fix For: 2.1.9, 2.2.1, 3.0 beta 1 > > > Currently the encoding option is not exposed as a command line parameter, so > users cannot specify a different encoding other than the System's default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9927) Security for MaterializedViews
[ https://issues.apache.org/jira/browse/CASSANDRA-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-9927: --- Component/s: Coordination > Security for MaterializedViews > -- > > Key: CASSANDRA-9927 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9927 > Project: Cassandra > Issue Type: Task > Components: Coordination >Reporter: T Jake Luciani >Assignee: Paulo Motta > Labels: materializedviews > Fix For: 3.0 beta 1 > > > We need to think about how to handle security wrt materialized views. Since > they are based on a source table we should possibly inherit the same security > model as that table. > However I can see cases where users would want to create different security > auth for different views. esp once we have CASSANDRA-9664 and users can > filter out sensitive data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Make compression ratio much more accurate
Repository: cassandra
Updated Branches:
refs/heads/trunk 811ffa7bf -> fa92ae66d
Make compression ratio much more accurate
patch by Brett Snyder; reviewed by Benjamin Lerer for CASSANDRA-10225
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fa92ae66
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fa92ae66
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fa92ae66
Branch: refs/heads/trunk
Commit: fa92ae66d3ac6966bd08e7eda06183695dc34905
Parents: 811ffa7
Author: Brett Snyder
Authored: Thu Nov 26 15:08:54 2015 +0100
Committer: Benjamin Lerer
Committed: Thu Nov 26 15:08:54 2015 +0100
--
CHANGES.txt | 1 +
NEWS.txt| 7 ++-
.../apache/cassandra/metrics/TableMetrics.java | 58 +++-
3 files changed, 37 insertions(+), 29 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa92ae66/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a952d10..37e60cb 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.2
+ * Make compression ratio much more accurate (CASSANDRA-10225)
* Optimize building of Clustering object when only one is created
(CASSANDRA-10409)
* Make index building pluggable (CASSANDRA-10681)
* Add sstable flush observer (CASSANDRA-10678)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa92ae66/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 41cccb4..2ccc27d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -20,8 +20,11 @@ New features
- Support for type casting has been added to the selection clause.
-
-
+
+Upgrading
+-
+ - The compression ratio metrics computation has been modified to be more
accurate.
+
3.0
===
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa92ae66/src/java/org/apache/cassandra/metrics/TableMetrics.java
--
diff --git a/src/java/org/apache/cassandra/metrics/TableMetrics.java
b/src/java/org/apache/cassandra/metrics/TableMetrics.java
index 3cd5b5b..fd69ea9 100644
--- a/src/java/org/apache/cassandra/metrics/TableMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/TableMetrics.java
@@ -24,13 +24,14 @@ import java.util.concurrent.TimeUnit;
import com.codahale.metrics.*;
import com.codahale.metrics.Timer;
+import com.google.common.collect.Iterables;
import com.google.common.collect.Maps;
import org.apache.cassandra.db.ColumnFamilyStore;
import org.apache.cassandra.db.Keyspace;
import org.apache.cassandra.db.Memtable;
import org.apache.cassandra.db.lifecycle.SSTableSet;
+import org.apache.cassandra.io.compress.CompressionMetadata;
import org.apache.cassandra.io.sstable.format.SSTableReader;
-import org.apache.cassandra.io.sstable.metadata.MetadataCollector;
import org.apache.cassandra.utils.EstimatedHistogram;
import org.apache.cassandra.utils.TopKSampler;
@@ -41,7 +42,6 @@ import static
org.apache.cassandra.metrics.CassandraMetricsRegistry.Metrics;
*/
public class TableMetrics
{
-
/** Total amount of data stored in the memtable that resides on-heap,
including column related overhead and partitions overwritten. */
public final Gauge memtableOnHeapSize;
/** Total amount of data stored in the memtable that resides off-heap,
including column related overhead and partitions overwritten. */
@@ -323,36 +323,14 @@ public class TableMetrics
{
public Double getValue()
{
-double sum = 0;
-int total = 0;
-for (SSTableReader sstable :
cfs.getSSTables(SSTableSet.CANONICAL))
-{
-if (sstable.getCompressionRatio() !=
MetadataCollector.NO_COMPRESSION_RATIO)
-{
-sum += sstable.getCompressionRatio();
-total++;
-}
-}
-return total != 0 ? sum / total : 0;
+return
computeCompressionRatio(cfs.getSSTables(SSTableSet.CANONICAL));
}
}, new Gauge() // global gauge
{
public Double getValue()
{
-double sum = 0;
-int total = 0;
-for (Keyspace keyspace : Keyspace.all())
-{
-for (SSTableReader sstable :
keyspace.getAllSSTables(SSTableSet.CANONICAL))
-{
-if (sstable.getCompressionRatio() !=
MetadataCollector.NO_COMPRESSION_RATIO)
-{
-sum += sstable.getCompressionRatio();
-
[jira] [Updated] (CASSANDRA-9917) MVs should validate gc grace seconds on the tables involved
[ https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-9917: --- Component/s: Coordination > MVs should validate gc grace seconds on the tables involved > --- > > Key: CASSANDRA-9917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9917 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Aleksey Yeschenko >Assignee: Paulo Motta > Labels: docs-impacting, materializedviews > Fix For: 3.0 beta 2 > > > For correctness reasons (potential resurrection of dropped values), batchlog > entries are TTLs with the lowest gc grace second of all the tables involved > in a batch. > It means that if gc gs is set to 0 in one of the tables, the batchlog entry > will be dead on arrival, and never replayed. > We should probably warn against such LOGGED writes taking place, in general, > but for MVs, we must validate that gc gs on the base table (and on the MV > table, if we should allow altering gc gs there at all), is never set too low, > or else. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8515) Commit log stop policy not enforced correctly during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-8515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-8515:
---
Component/s: Lifecycle
Coordination
> Commit log stop policy not enforced correctly during startup
> -
>
> Key: CASSANDRA-8515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8515
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination, Lifecycle
>Reporter: Richard Low
>Assignee: Paulo Motta
>Priority: Minor
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> If the commit log directory has no free space, Cassandra hangs on startup.
> The main thread is waiting:
> {code}
> "main" prio=9 tid=0x7fefe400f800 nid=0x1303 waiting on condition
> [0x00010b9c1000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007dc8c5fc8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.cassandra.db.commitlog.CommitLogAllocator.fetchSegment(CommitLogAllocator.java:137)
> at
> org.apache.cassandra.db.commitlog.CommitLog.activateNextSegment(CommitLog.java:299)
> at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:73)
> at
> org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:53)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:360)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:339)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:211)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:699)
> at
> org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:208)
> at
> org.apache.cassandra.db.SystemKeyspace.updateSchemaVersion(SystemKeyspace.java:390)
> - locked <0x0007de2f2ce0> (a java.lang.Class for
> org.apache.cassandra.db.SystemKeyspace)
> at org.apache.cassandra.config.Schema.updateVersion(Schema.java:384)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:532)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:270)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
> {code}
> but COMMIT-LOG-ALLOCATOR is RUNNABLE:
> {code}
> "COMMIT-LOG-ALLOCATOR" prio=9 tid=0x7fefe5402800 nid=0x7513 in
> Object.wait() [0x000118252000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:116)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> but making no progress.
> This behaviour has changed since 1.2 (see CASSANDRA-5737).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10341) Streaming does not guarantee cache invalidation
[ https://issues.apache.org/jira/browse/CASSANDRA-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10341: Component/s: Streaming and Messaging > Streaming does not guarantee cache invalidation > --- > > Key: CASSANDRA-10341 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10341 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Benedict >Assignee: Paulo Motta > Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1 > > > Looking at the code, we attempt to invalidate the row cache for any rows we > receive via streaming, however we invalidate them immediately, before the new > data is available. So, if it is requested (which is likely if it is "hot") in > the interval, it will be re-cached and not invalidated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10186) Windows dtest 3.0: schema_metadata_test.py:TestSchemaMetadata.indexes_test fails
[
https://issues.apache.org/jira/browse/CASSANDRA-10186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10186:
Component/s: Testing
> Windows dtest 3.0: schema_metadata_test.py:TestSchemaMetadata.indexes_test
> fails
>
>
> Key: CASSANDRA-10186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10186
> Project: Cassandra
> Issue Type: Sub-task
> Components: Testing
>Reporter: Joshua McKenzie
>Assignee: Paulo Motta
> Labels: Windows
> Fix For: 3.0 beta 2
>
>
> {noformat}
> ERROR: indexes_test (schema_metadata_test.TestSchemaMetadata)
> --
> Traceback (most recent call last):
> File "c:\src\cassandra-dtest\schema_metadata_test.py", line 660, in
> indexes_test
> verify_indexes_table(self.cluster.version(), self.cluster.version(),
> 'ks', self.session)
> File "c:\src\cassandra-dtest\schema_metadata_test.py", line 30, in
> verify_indexes_table
> meta = session.cluster.metadata.keyspaces[keyspace].indexes[index_name]
> KeyError: 'idx__test_indexes'
> >> begin captured logging <<
> dtest: DEBUG: removing ccm cluster test at: c:\temp\dtest-h2pni_
> dtest: DEBUG: clearing ssl stores from [c:\temp\dtest-h2pni_] directory
> dtest: DEBUG: cluster ccm directory: c:\temp\dtest-yb4kzh
> - >> end captured logging << -
> {noformat}
> History consistent. Reproduces locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10646) crash_during_decommission_test dtest fails on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-10646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10646:
Component/s: Testing
> crash_during_decommission_test dtest fails on windows
> -
>
> Key: CASSANDRA-10646
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10646
> Project: Cassandra
> Issue Type: Sub-task
> Components: Testing
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.1, 3.1
>
>
> {{topology_test.py:TestTopology.crash_during_decommission_test}} flaps on on
> C* 3.0 on Windows:
> http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/100/testReport/topology_test/TestTopology/crash_during_decommission_test/history/
> Since this test raises 2 errors on failure, there are 2 histories on CassCI
> for it:
> http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/100/testReport/topology_test/TestTopology/crash_during_decommission_test_2/history/
> It looks like it fails because of contention over the temporary file where
> {{cassandra.env}} is stored:
> http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/101/testReport/junit/topology_test/TestTopology/crash_during_decommission_test/
> Looks like this happens when {{nodetool status}} is called, since
> {{nodetool}} sources {{cassandra-env.sh}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10098) Windows dtest 3.0: commitlog_test.py:TestCommitLog.small_segment_size_test fails
[
https://issues.apache.org/jira/browse/CASSANDRA-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10098:
Component/s: Testing
> Windows dtest 3.0: commitlog_test.py:TestCommitLog.small_segment_size_test
> fails
>
>
> Key: CASSANDRA-10098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10098
> Project: Cassandra
> Issue Type: Sub-task
> Components: Testing
>Reporter: Joshua McKenzie
>Assignee: Paulo Motta
> Labels: Windows
> Fix For: 3.0 beta 1
>
>
> {noformat}
> File "D:\Python27\lib\unittest\case.py", line 329, in run
> testMethod()
> File
> "D:\jenkins\workspace\cassandra-3.0_dtest_win32\cassandra-dtest\tools.py",
> line 243, in wrapped
> f(obj)
> File
> "D:\jenkins\workspace\cassandra-3.0_dtest_win32\cassandra-dtest\commitlog_test.py",
> line 226, in small_segment_size_test
> self._commitlog_test(segment_size_in_mb, 62.5, 13, files_error=0.2)
> File
> "D:\jenkins\workspace\cassandra-3.0_dtest_win32\cassandra-dtest\commitlog_test.py",
> line 99, in _commitlog_test
> error=files_error)
> File
> "D:\jenkins\workspace\cassandra-3.0_dtest_win32\cassandra-dtest\assertions.py",
> line 62, in assert_almost_equal
> assert vmin > vmax * (1.0 - error) or vmin == vmax, "values not within
> %.2f%% of the max: %s" % (error * 100, args)
> 'values not within 20.00% of the max: (10, 13)\n >> begin
> captured logging << \ndtest: DEBUG: cluster ccm
> directory: d:\\temp\\dtest-qnguzs\n- >> end captured
> logging << -'
> {noformat}
> Failure history:
> [consistent|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/17/testReport/junit/commitlog_test/TestCommitLog/small_segment_size_test/]
> env: Both ci and local
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10223) Windows utest 3.0: CompactionsCQLTest flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10223: Component/s: Testing Compaction > Windows utest 3.0: CompactionsCQLTest flaky > --- > > Key: CASSANDRA-10223 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10223 > Project: Cassandra > Issue Type: Sub-task > Components: Compaction, Testing >Reporter: Paulo Motta >Assignee: Paulo Motta >Priority: Minor > Fix For: 3.0.0 rc1 > > Attachments: 10223-3.0.patch > > > Every [now and > then|http://cassci.datastax.com/view/win32/job/cassandra-3.0_utest_win32/23/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/history/] > are are failures on > [testTriggerMinorCompactionSTCS|http://cassci.datastax.com/view/win32/job/cassandra-3.0_utest_win32/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS/] > or > [testTriggerMinorCompactionSTCS|http://cassci.datastax.com/view/win32/job/cassandra-3.0_utest_win32/10/testReport/junit/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionSTCS/]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-1:
Component/s: Tools
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9964) Document post-2.1 caching table options syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-9964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-9964:
---
Component/s: Documentation and Website
> Document post-2.1 caching table options syntax
> --
>
> Key: CASSANDRA-9964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9964
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation and Website
>Reporter: Aleksey Yeschenko
>Assignee: Paulo Motta
>Priority: Minor
> Fix For: 2.1.10, 2.2.2, 3.0.0 rc1
>
>
> CASSANDRA-5357 added new syntax for caching for {{CREATE TABLE}} in 2.1, but
> [documentation|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile]
> hasn't been updated accordingly.
> Now that the old options are gone completely after CASSANDRA-9712, we *must*
> update the CQL spec.
> [DS
> Docs|http://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_set_caching_t.html]
> have been up to date for a while.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10260) NPE in SSTableReader.invalidateCacheKey
[
https://issues.apache.org/jira/browse/CASSANDRA-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10260:
Component/s: Local Write-Read Paths
Coordination
> NPE in SSTableReader.invalidateCacheKey
> ---
>
> Key: CASSANDRA-10260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10260
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination, Local Write-Read Paths
> Environment: 2.1.7
>Reporter: Jeff Jirsa
>Assignee: Paulo Motta
> Fix For: 2.1.8
>
>
> {code}
> ERROR [NonPeriodicTasks:1] 2015-09-03 05:24:51,056 CassandraDaemon.java:223 -
> Exception in thread Thread[NonPeriodicTasks:1,5,main]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.io.sstable.SSTableReader.invalidateCacheKey(SSTableReader.java:1445)
> ~[apache-cassandra-2.1.7.jar:2.1.7]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter$1.run(SSTableRewriter.java:323)
> ~[apache-cassandra-2.1.7.jar:2.1.7]
> at
> org.apache.cassandra.io.sstable.SSTableReader$5.run(SSTableReader.java:1024)
> ~[apache-cassandra-2.1.7.jar:2.1.7]
> at
> org.apache.cassandra.io.sstable.SSTableReader$InstanceTidier$1.run(SSTableReader.java:2146)
> ~[apache-cassandra-2.1.7.jar:2.1.7]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> {code}
> Seen in 2.1.7 in a node running cleanup. May be fixed already, logging to be
> safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9806) some TTL test are failing on trunk: losing data after restart?
[ https://issues.apache.org/jira/browse/CASSANDRA-9806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-9806: --- Component/s: Testing > some TTL test are failing on trunk: losing data after restart? > --- > > Key: CASSANDRA-9806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9806 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Alan Boudreault >Assignee: Paulo Motta >Priority: Blocker > Fix For: 3.0.0 rc2 > > > ttl_test.TestDistributedTTL.ttl_is_respected_on_delayed_replication_test is > failing and ttl_test.TestDistributedTTL.ttl_is_respected_on_repair_test are > failing: > http://cassci.datastax.com/view/trunk/job/trunk_dtest/346/testReport/junit/ttl_test/TestDistributedTTL/ttl_is_respected_on_delayed_replication_test/ > http://cassci.datastax.com/view/trunk/job/trunk_dtest/346/testReport/junit/ttl_test/TestDistributedTTL/ttl_is_respected_on_repair_test/ > After some debugging, I noticed a strange behaviour. It looks like some data > disappear after a node restart, even if the row has no TTL set. Here a test > example where I see the issue with latest trunk: > https://gist.github.com/aboudreault/94cb552750a186ca853d -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10347) Bulk Loader API could not tolerate even node failure
[ https://issues.apache.org/jira/browse/CASSANDRA-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10347: Component/s: Tools > Bulk Loader API could not tolerate even node failure > > > Key: CASSANDRA-10347 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10347 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Shenghua Wan >Assignee: Paulo Motta > Fix For: 2.1.10, 2.2.2, 3.0.0 rc2 > > Attachments: AbstractBulkRecordWriter.java > > > When user uses CqlBulkOutputFormat, it tries to stream to all the nodes in > the token range, which includes the dead nodes. Therefore, the stream failed. > There was a design in C* API to allow stream() method to have a list of > ignore hosts, but it was not utilized. > The empty-argument stream() method is called in all existing versions of C*, > i.e. > in v2.0.11, > https://github.com/apache/cassandra/blob/cassandra-2.0.11/src/java/org/apache/cassandra/hadoop/AbstractBulkRecordWriter.java#L122 > in v2.1.5, > https://github.com/apache/cassandra/blob/cassandra-2.1.5/src/java/org/apache/cassandra/hadoop/AbstractBulkRecordWriter.java#L122 > and current trunk branch > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/hadoop/cql3/CqlBulkRecordWriter.java#L241 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10451:
Component/s: Testing
> Fix
> batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test
> on CassCI
> --
>
> Key: CASSANDRA-10451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10451
> Project: Cassandra
> Issue Type: Sub-task
> Components: Testing
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This is a recent regression:
> http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
> Based on [when it started
> failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes],
> it looks like the regression was introduced by [the recent logging
> changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa].
> Pinging [~blerer] and [~pauloricardomg] to have a look.
> My initial guess was that the logs the test depends on were moved to the new
> debug log. However, the tests passes when I run it manually on openstack, so
> it could just be a configuration issue on CassCI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10417) Windows dtest 3.0: creating_and_dropping_table_with_2ary_indexes_test
[ https://issues.apache.org/jira/browse/CASSANDRA-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10417: Component/s: Testing > Windows dtest 3.0: creating_and_dropping_table_with_2ary_indexes_test > - > > Key: CASSANDRA-10417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10417 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > [schema_metadata_test.TestSchemaMetadata.creating_and_dropping_table_with_2ary_indexes_test|http://cassci.datastax.com/view/win32/job/cassandra-3.0_dtest_win32/72/testReport/schema_metadata_test/TestSchemaMetadata/creating_and_dropping_table_with_2ary_indexes_test/] > fails on cassandra-3.0 under Windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10293) Re-populate token metadata after commit log replay
[ https://issues.apache.org/jira/browse/CASSANDRA-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10293: Component/s: Lifecycle Coordination > Re-populate token metadata after commit log replay > -- > > Key: CASSANDRA-10293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10293 > Project: Cassandra > Issue Type: Bug > Components: Coordination, Lifecycle >Reporter: Alan Boudreault >Assignee: Paulo Motta >Priority: Minor > Fix For: 3.0.0 rc2 > > Attachments: mv_repair_test.sh > > > I've noticed this while working on another task: a node that was currently > down was not showed in my nodetool status. The node had joined the cluster > and was displayed in the status before. > I've attached [^mv_repair_test.sh] to reproduce the issue. After the > execution of the script, just try a: ccm node3 nodetool status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10453) Fix compression_cql_options_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10453: Component/s: Testing > Fix compression_cql_options_test dtest > -- > > Key: CASSANDRA-10453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10453 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This has been failing hard for a while: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/testReport/junit/compression_test/TestCompression/compression_cql_options_test/history/ > This regression, like CASSANDRA-10451, started when the recent log changes > were introduced: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/changes > I also can't reproduce on OpenStack. Pinging [~pauloricardomg] and [~blerer] > again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10459) Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10459: Component/s: Testing > Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest > -- > > Key: CASSANDRA-10459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10459 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This test on large columns is failing: > http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/largecolumn_test/TestLargeColumn/cleanup_test/ > and it's been failing for a while: > http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/junit/largecolumn_test/TestLargeColumn/cleanup_test/history/ > I've reproduced the failure on OpenStack, so it's not just a CassCI problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10525) Hints directory not created on debian packaged install
[
https://issues.apache.org/jira/browse/CASSANDRA-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10525:
Component/s: Configuration
> Hints directory not created on debian packaged install
> --
>
> Key: CASSANDRA-10525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10525
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> Reproduction steps:
> * Create debian package install with {{dpkg-buildpackage -uc -us}}
> * Install package with {{sudo dpkg -i ../cassandra_3.0.0\~rc1_all.deb}}
> * Start cassandra with {{sudo service cassandra start}}
> Cassandra does not start with the following message on
> {{/var/log/cassandra/system.log}}:
> {noformat}
> DEBUG [main] 2015-10-14 09:28:36,083 StartupChecks.java:191 - Checking
> directory /var/lib/cassandra/data
> DEBUG [main] 2015-10-14 09:28:36,087 StartupChecks.java:191 - Checking
> directory /var/lib/cassandra/commitlog
> DEBUG [main] 2015-10-14 09:28:36,087 StartupChecks.java:191 - Checking
> directory /var/lib/cassandra/saved_caches
> DEBUG [main] 2015-10-14 09:28:36,087 StartupChecks.java:191 - Checking
> directory /hints
> WARN [main] 2015-10-14 09:28:36,088 StartupChecks.java:197 - Directory
> /hints doesn't exist
> ERROR [main] 2015-10-14 09:28:36,088 CassandraDaemon.java:702 - Has no
> permission to create directory /hints
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9839) Move crc_check_chance out of compressions options
[ https://issues.apache.org/jira/browse/CASSANDRA-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-9839: --- Component/s: Configuration > Move crc_check_chance out of compressions options > - > > Key: CASSANDRA-9839 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9839 > Project: Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Aleksey Yeschenko >Assignee: Paulo Motta >Priority: Minor > Labels: client-impacting, docs-impacting > Fix For: 3.0.0 rc1 > > > Follow up to CASSANDRA-8384. The option doesn't belong to compression params > - it doesn't affect compression, itself, and isn't passed to compressors upon > initialization. > While it's true that it is (currently) only being honored when reading > compressed sstables, it still doesn't belong to compression params (and is > causing CASSANDRA-7978 -like issues). > [~tjake] suggested we should make it an option of its own, and I think we > should. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10553) MAX_HEAP_SIZE environment variable ignored on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10553:
Component/s: Lifecycle
> MAX_HEAP_SIZE environment variable ignored on Windows
> -
>
> Key: CASSANDRA-10553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Labels: windows
>
> [~philipthompson] had a look at a few Windows timeouts on CassCI:
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/86/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/87/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/88/console
> The offending tests were
> {{bootstrap_test.py:TestBootstrap.killed_wiped_node_cannot_join_test}} in two
> runs and
> {{consistency_test.py:TestAccuracy.test_network_topology_strategy_counters}}
> in one. In the latter case, {{killed_wiped_node_cannot_join_test}} passed, so
> this doesn't happen 100% of the time.
> Philip has reproduced this locally
> ({{bootstrap_test.py:TestBootstrap.decommissioned_wiped_node_can_join_test}}),
> so it's not purely a CassCI problem. The cause there seems to be an OOM --
> when running the tests, he sees 8GB "committed" in the process explorer, but
> only 4 actually used.
> I'm opening this ticket to track work on configuring the Windows dtests so
> this doesn't happen on CassCI anymore. Assigning [~JoshuaMcKenzie] for the
> moment, but [~pauloricardomg] might be able to make short work of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7290) Compaction strategy is not reloaded when compaction strategy options is updated
[
https://issues.apache.org/jira/browse/CASSANDRA-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-7290:
---
Component/s: Compaction
> Compaction strategy is not reloaded when compaction strategy options is
> updated
> ---
>
> Key: CASSANDRA-7290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7290
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Fix For: 2.0.9
>
>
> The AbstractCompactionStrategy constructor receives an options map on its
> constructor:
> {code:java}
> protected AbstractCompactionStrategy(ColumnFamilyStore cfs, Map String> options)
> {
> assert cfs != null;
> this.cfs = cfs;
> this.options = options;
> ...
> {code}
> This map is currently the same reference as
> CFMetadata.compactionStrategyOptions, so ColumnFamilyStore.reload() does not
> reload the compaction strategy when a compaction strategy option changes:
> {code:java}
> private void maybeReloadCompactionStrategy()
> {
> // Check if there is a need for reloading
> if
> (metadata.compactionStrategyClass.equals(compactionStrategy.getClass())
> &&
> metadata.compactionStrategyOptions.equals(compactionStrategy.options))
> //metadata.compactionStrategyOptions == compactionStrategy.options, so
> compaction is never reloaded
> return;
> {code}
> I spotted this in my test, when I tried changing the value of
> "unchecked_tombstone_compaction" from false to true and calling
> ColumnFamilyStore.reload() was not reloading the compaction strategy. I don't
> know if ColumnFamilyStore.reload() is only called during tests, or also
> whenever the schema changes.
> In order to fix the bug, I made AbstractCompactionStrategy.options an
> ImmutableMap, so if CFMetadata.compactionStrategyOptions is updated,
> ColumnFamilyStore.maybeReloadCompactionStrategy will actually reload the
> compaction strategy:
> {code:java}
> protected AbstractCompactionStrategy(ColumnFamilyStore cfs, Map String> options)
> {
> assert cfs != null;
> this.cfs = cfs;
> this.options = ImmutableMap.copyOf(options);
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7357) Cleaning up snapshots on startup leftover from repairs that got interrupted
[ https://issues.apache.org/jira/browse/CASSANDRA-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-7357: --- Component/s: Streaming and Messaging > Cleaning up snapshots on startup leftover from repairs that got interrupted > --- > > Key: CASSANDRA-7357 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7357 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Stephen Johnson >Assignee: Paulo Motta >Priority: Minor > Fix For: 2.1.9, 2.2.1, 3.0 alpha 1 > > > When a repair is interrupted, such as a restart, it can leave a snapshot > behind on disk. These could be checked for and cleared possibly on startup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7445) Support Thrift tables clustering columns on CqlPagingInputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-7445: --- Component/s: Tools > Support Thrift tables clustering columns on CqlPagingInputFormat > > > Key: CASSANDRA-7445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7445 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Paulo Motta >Assignee: Paulo Motta > Fix For: 1.2.18 > > Attachments: 1.2-CASSANDRA-7445-withPigTests.txt, > 1.2-CASSANDRA-7445.txt > > > CASSANDRA-5752 introduced support to thrift tables on CQLPagingInputFormat > via the retrieveKeysForThriftTables() method. > However, this method only retrieves partition keys from CFMetaData, so > clustering columns are ignored. > So, when the RowIterator tries to fetch the next page of a wide-row thrift > CF, it ignores the clustering column altogether, going to the next partition > token. So, only cassandra.input.page.row.size CQL rows are retrieved for each > partition key. > CqlRecordWriter had the same issue and was fixed on > bcfe352ea6ed3786f274b90191f988210360689d (CASSANDRA-5718). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7431) Hadoop integration does not perform reverse DNS lookup correctly on EC2
[
https://issues.apache.org/jira/browse/CASSANDRA-7431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-7431:
---
Component/s: Tools
> Hadoop integration does not perform reverse DNS lookup correctly on EC2
> ---
>
> Key: CASSANDRA-7431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7431
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Attachments: 2.0-CASSANDRA-7431.txt
>
>
> The split assignment on AbstractColumnFamilyInputFormat:247 peforms a reverse
> DNS lookup of Cassandra IPs in order to preserve locality in Hadoop (task
> trackers are identified by hostnames).
> However, the reverse lookup of an EC2 IP does not yield the EC2 hostname of
> that endpoint when running from an EC2 instance due to the use of
> InetAddress.getHostname().
> In order to show this, consider the following piece of code:
> {code:title=DnsResolver.java|borderStyle=solid}
> public class DnsResolver {
> public static void main(String[] args) throws Exception {
> InetAddress namenodePublicAddress = InetAddress.getByName(args[0]);
> System.out.println("getHostAddress: " +
> namenodePublicAddress.getHostAddress());
> System.out.println("getHostName: " +
> namenodePublicAddress.getHostName());
> }
> }
> {code}
> When this code is run from my machine to perform reverse lookup of an EC2 IP,
> the output is:
> {code:none}
> ➜ java DnsResolver 54.201.254.99
> getHostAddress: 54.201.254.99
> getHostName: ec2-54-201-254-99.compute-1.amazonaws.com
> {code}
> When this code is executed from inside an EC2 machine, the output is:
> {code:none}
> ➜ java DnsResolver 54.201.254.99
> getHostAddress: 54.201.254.99
> getHostName: 54.201.254.99
> {code}
> However, when using linux tools such as "host" or "dig", the EC2 hostname is
> properly resolved from the EC2 instance, so there's some problem with Java's
> InetAddress.getHostname() and EC2.
> Two consequences of this bug during AbstractColumnFamilyInputFormat split
> definition are:
> 1) If the Hadoop cluster is configured to use EC2 public DNS, the locality
> will be lost, because Hadoop will try to match the CFIF split location
> (public IP) with the task tracker location (public DNS), so no matches will
> be found.
> 2) If the Cassandra nodes' broadcast_address is set to public IPs, all hadoop
> communication will be done via the public IP, what will incurr additional
> transference charges. If the public IP is mapped to the EC2 DNS during split
> definition, when the task is executed, ColumnFamilyRecordReader will resolve
> the public DNS to the private IP of the instance, so there will be not
> additional charges.
> A similar bug was filed in the WHIRR project:
> https://issues.apache.org/jira/browse/WHIRR-128
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6436) AbstractColumnFamilyInputFormat does not use start and end tokens configured via ConfigHelper.setInputRange()
[
https://issues.apache.org/jira/browse/CASSANDRA-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-6436:
---
Component/s: Tools
> AbstractColumnFamilyInputFormat does not use start and end tokens configured
> via ConfigHelper.setInputRange()
> -
>
> Key: CASSANDRA-6436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6436
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Labels: hadoop, patch
> Fix For: 2.0.7
>
> Attachments: cassandra-1.2-6436.txt, cassandra-1.2-6436.txt
>
>
> ConfigHelper allows to set a token input range via the setInputRange(conf,
> startToken, endToken) call (ConfigHelper:254).
> We used this feature to limit a hadoop job range to a single Cassandra node's
> range, or even to single row key, mostly for testing purposes.
> This worked before the fix for CASSANDRA-5536
> (https://github.com/apache/cassandra/commit/aaf18bd08af50bbaae0954d78d5e6cbb684aded9),
> but after this ColumnFamilyInputFormat never uses the value of
> KeyRange.start_token when defining the input splits
> (AbstractColumnFamilyInputFormat:142-160), but only KeyRange.start_key, which
> needs an order preserving partitioner to work.
> I propose the attached fix in order to allow defining Cassandra token ranges
> for a given Hadoop job even when using a non-order preserving partitioner.
> Example use of ConfigHelper.setInputRange(conf, startToken, endToken) to
> limit the range to a single Cassandra Key with RandomPartitioner:
> IPartitioner part = ConfigHelper.getInputPartitioner(job.getConfiguration());
> Token token = part.getToken(ByteBufferUtil.bytes("Cassandra Key"));
> BigInteger endToken = (BigInteger) new
> BigIntegerConverter().convert(BigInteger.class,
> part.getTokenFactory().toString(token));
> BigInteger startToken = endToken.subtract(new BigInteger("1"));
> ConfigHelper.setInputRange(job.getConfiguration(), startToken.toString(),
> endToken.toString());
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7757) Possible Atomicity Violations in StreamSession and ThriftSessionManager
[
https://issues.apache.org/jira/browse/CASSANDRA-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-7757:
---
Component/s: Streaming and Messaging
> Possible Atomicity Violations in StreamSession and ThriftSessionManager
> ---
>
> Key: CASSANDRA-7757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7757
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Diogo Sousa
>Assignee: Paulo Motta
>Priority: Minor
> Fix For: 2.1.9, 2.2.1, 3.0 alpha 1
>
>
> I'm developing a tool for atomicity violation detection and I think it have
> found two atomicity violations in cassandra.
> In org.apache.cassandra.streaming.StreamSession there might be an atomicity
> violation in method addTransferFiles(), lines 310-314:
> {noformat}
> 310: StreamTransferTask task = transfers.get(cfId);
> if (task == null)
> {
> task = new StreamTransferTask(this, cfId);
> 314: transfers.put(cfId, task);
> }
> {noformat}
> A concurrent thread can insert a transfer with the same uuid creating two
> StreamTransferTask, and only one get into "transfers".
> In org.apache.cassandra.thrift.ThriftSessionManager, a simular situation can
> occur in method currentSession(), lines 57-61:
> {noformat}
> 57: ThriftClientState cState = activeSocketSessions.get(socket);
> if (cState == null)
> {
> cState = new ThriftClientState(socket);
> 51: activeSocketSessions.put(socket, cState);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6563) TTL histogram compactions not triggered at high "Estimated droppable tombstones" rate
[
https://issues.apache.org/jira/browse/CASSANDRA-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-6563:
---
Component/s: Compaction
> TTL histogram compactions not triggered at high "Estimated droppable
> tombstones" rate
> -
>
> Key: CASSANDRA-6563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6563
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: 1.2.12ish
>Reporter: Chris Burroughs
>Assignee: Paulo Motta
> Fix For: 2.0.9
>
> Attachments: 1.2.16-CASSANDRA-6563-v2.txt,
> 1.2.16-CASSANDRA-6563-v3.txt, 1.2.16-CASSANDRA-6563.txt,
> 2.0-CASSANDRA-6563-v3.txt, 2.0.7-CASSANDRA-6563.txt, patch-v1-iostat.png,
> patch-v1-range1.png, patch-v2-range3.png, patched-droppadble-ratio.png,
> patched-storage-load.png, patched1-compacted-bytes.png,
> patched2-compacted-bytes.png, unpatched-droppable-ratio.png,
> unpatched-storage-load.png, unpatched1-compacted-bytes.png,
> unpatched2-compacted-bytes.png
>
>
> I have several column families in a largish cluster where virtually all
> columns are written with a (usually the same) TTL. My understanding of
> CASSANDRA-3442 is that sstables that have a high ( > 20%) estimated
> percentage of droppable tombstones should be individually compacted. This
> does not appear to be occurring with size tired compaction.
> Example from one node:
> {noformat}
> $ ll /data/sstables/data/ks/Cf/*Data.db
> -rw-rw-r-- 31 cassandra cassandra 26651211757 Nov 26 22:59
> /data/sstables/data/ks/Cf/ks-Cf-ic-295562-Data.db
> -rw-rw-r-- 31 cassandra cassandra 6272641818 Nov 27 02:51
> /data/sstables/data/ks/Cf/ks-Cf-ic-296121-Data.db
> -rw-rw-r-- 31 cassandra cassandra 1814691996 Dec 4 21:50
> /data/sstables/data/ks/Cf/ks-Cf-ic-320449-Data.db
> -rw-rw-r-- 30 cassandra cassandra 10909061157 Dec 11 17:31
> /data/sstables/data/ks/Cf/ks-Cf-ic-340318-Data.db
> -rw-rw-r-- 29 cassandra cassandra 459508942 Dec 12 10:37
> /data/sstables/data/ks/Cf/ks-Cf-ic-342259-Data.db
> -rw-rw-r-- 1 cassandra cassandra 336908 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342307-Data.db
> -rw-rw-r-- 1 cassandra cassandra 2063935 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342309-Data.db
> -rw-rw-r-- 1 cassandra cassandra 409 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342314-Data.db
> -rw-rw-r-- 1 cassandra cassandra31180007 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342319-Data.db
> -rw-rw-r-- 1 cassandra cassandra 2398345 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342322-Data.db
> -rw-rw-r-- 1 cassandra cassandra 21095 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342331-Data.db
> -rw-rw-r-- 1 cassandra cassandra 81454 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342335-Data.db
> -rw-rw-r-- 1 cassandra cassandra 1063718 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342339-Data.db
> -rw-rw-r-- 1 cassandra cassandra 127004 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342344-Data.db
> -rw-rw-r-- 1 cassandra cassandra 146785 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342346-Data.db
> -rw-rw-r-- 1 cassandra cassandra 697338 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342351-Data.db
> -rw-rw-r-- 1 cassandra cassandra 3921428 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342367-Data.db
> -rw-rw-r-- 1 cassandra cassandra 240332 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342370-Data.db
> -rw-rw-r-- 1 cassandra cassandra 45669 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342374-Data.db
> -rw-rw-r-- 1 cassandra cassandra53127549 Dec 12 12:03
> /data/sstables/data/ks/Cf/ks-Cf-ic-342375-Data.db
> -rw-rw-r-- 16 cassandra cassandra 12466853166 Dec 25 22:40
> /data/sstables/data/ks/Cf/ks-Cf-ic-396473-Data.db
> -rw-rw-r-- 12 cassandra cassandra 3903237198 Dec 29 19:42
> /data/sstables/data/ks/Cf/ks-Cf-ic-408926-Data.db
> -rw-rw-r-- 7 cassandra cassandra 3692260987 Jan 3 08:25
> /data/sstables/data/ks/Cf/ks-Cf-ic-427733-Data.db
> -rw-rw-r-- 4 cassandra cassandra 3971403602 Jan 6 20:50
> /data/sstables/data/ks/Cf/ks-Cf-ic-437537-Data.db
> -rw-rw-r-- 3 cassandra cassandra 1007832224 Jan 7 15:19
> /data/sstables/data/ks/Cf/ks-Cf-ic-440331-Data.db
> -rw-rw-r-- 2 cassandra cassandra 896132537 Jan 8 11:05
> /data/sstables/data/ks/Cf/ks-Cf-ic-447740-Data.db
> -rw-rw-r-- 1 cassandra cassandra 963039096 Jan 9 04:59
> /data/sstables/data/ks/Cf/ks-Cf-ic-449425-Data.db
> -rw-rw-r-- 1 cassandra cassandra 232168351 Jan 9 10:14
> /data/sstables/data/ks/Cf/ks-Cf-ic-450287-Data.db
> -rw-rw-r-- 1 cassandra cassandra73126319 Jan 9 11:28
> /data/sstables/data/ks/Cf/ks-Cf-ic-450307-Data.db
> -
