[jira] [Updated] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 3.0.8
[
https://issues.apache.org/jira/browse/CASSANDRA-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anuja Mandlecha updated CASSANDRA-13513:
Environment: DSE 5.0.8, cqlsh 5.0.1 , Cassandra 3.0.12.1656 , Ubuntu 14.04
(was: DSE 5.0.2 ,Cassandra 3.0.8 Ubuntu 14.04)
> Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to
> 3.0.8
> --
>
> Key: CASSANDRA-13513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13513
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: DSE 5.0.8, cqlsh 5.0.1 , Cassandra 3.0.12.1656 , Ubuntu
> 14.04
>Reporter: Anuja Mandlecha
>
> Hi,
> While querying Cassandra table using DBeaver or using DataStax Node.js Driver
> getting below error.
> {code}
> WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_101]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> {code}
> Query used is
> {code}
> select * from dynocloud.user_info where company_name='DS' allow filtering;
> {code}
> This query returns data when run in cql shell.
> Also if we give limit 100 to the same query or change the value to
> company_name, the query returns results. The index definition is
> {code}
> CREATE INDEX company_name_userindex ON dynocloud.user_info (company_name);
> {code}
> Thanks,
> Anuja Mandlecha
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 3.0.8
[
https://issues.apache.org/jira/browse/CASSANDRA-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anuja Mandlecha updated CASSANDRA-13513:
Description:
Hi,
While querying Cassandra table using DBeaver or using DataStax Node.js Driver
getting below error.
WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-2,5,main]: {}
java.lang.AssertionError: null
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_101]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
Query used is
select * from dynocloud.user_info where company_name='DS' allow filtering;
This query returns data when run in cql shell.
Also if we give limit 100 to the same query or change the value to
company_name, the query returns results. The index definition is
CREATE INDEX company_name_userindex ON dynocloud.user_info (company_name);
Thanks,
Anuja Mandlecha
was:
Hi,
While querying Cassandra table using DBeaver or using DataStax Node.js Driver
getting below error.
WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-2,5,main]: {}
java.lang.AssertionError: null
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
[jira] [Updated] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 3.0.8
[
https://issues.apache.org/jira/browse/CASSANDRA-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anuja Mandlecha updated CASSANDRA-13513:
Description:
Hi,
While querying Cassandra table using DBeaver or using DataStax Node.js Driver
getting below error.
WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-2,5,main]: {}
java.lang.AssertionError: null
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_101]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
Query used is
select * from dynocloud.user_info where company_name='DS' allow filtering;
This query returns data when run in cql shell. Whereas if we run a query like
select * from dynocloud.user_info where company_name='DS' limit 10;
it returns the data.
Thanks,
Anuja Mandlecha
was:
Hi,
While querying Cassandra table using DBeaver or using driver getting below
error.
WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-2,5,main]: {}
java.lang.AssertionError: null
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
[jira] [Updated] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to 3.0.8
[
https://issues.apache.org/jira/browse/CASSANDRA-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anuja Mandlecha updated CASSANDRA-13513:
Summary: Getting java.lang.AssertionError after upgrade from Cassandra
2.1.17.1428 to 3.0.8 (was: Getting java.lang.AssertionError after upgrade from
2.1.17.1428 to 3.0.8)
> Getting java.lang.AssertionError after upgrade from Cassandra 2.1.17.1428 to
> 3.0.8
> --
>
> Key: CASSANDRA-13513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13513
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: DSE 5.0.2 ,Cassandra 3.0.8 Ubuntu 14.04
>Reporter: Anuja Mandlecha
>
> Hi,
> While querying Cassandra table using DBeaver or using driver getting below
> error.
> WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_101]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-3.0.8.1293.jar:3.0.8.1293]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Query used is
> select * from dynocloud.user_info where company_name='DS' allow filtering;
> This query returns data when run in cql shell. Whereas if we run a query like
> select * from dynocloud.user_info where company_name='DS' limit 10;
> it returns the data.
> Thanks,
> Anuja Mandlecha
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13513) Getting java.lang.AssertionError after upgrade from 2.1.17.1428 to 3.0.8
Anuja Mandlecha created CASSANDRA-13513:
---
Summary: Getting java.lang.AssertionError after upgrade from
2.1.17.1428 to 3.0.8
Key: CASSANDRA-13513
URL: https://issues.apache.org/jira/browse/CASSANDRA-13513
Project: Cassandra
Issue Type: Bug
Components: CQL
Environment: DSE 5.0.2 ,Cassandra 3.0.8 Ubuntu 14.04
Reporter: Anuja Mandlecha
Hi,
While querying Cassandra table using DBeaver or using driver getting below
error.
WARN [SharedPool-Worker-2] 2017-05-09 12:55:18,654
AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-2,5,main]: {}
java.lang.AssertionError: null
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.findEntry(CompositesSearcher.java:228)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.index.internal.composites.CompositesSearcher$1Transform.applyToRow(CompositesSearcher.java:218)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:300)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2466)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_101]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[cassandra-all-3.0.8.1293.jar:3.0.8.1293]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
Query used is
select * from dynocloud.user_info where company_name='DS' allow filtering;
This query returns data when run in cql shell. Whereas if we run a query like
select * from dynocloud.user_info where company_name='DS' limit 10;
it returns the data.
Thanks,
Anuja Mandlecha
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7212) Allow to switch user within CQLSH session
[ https://issues.apache.org/jira/browse/CASSANDRA-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366688#comment-14366688 ] Anuja Mandlecha commented on CASSANDRA-7212: Sure you can take it since I am busy in some other high priority tasks. Allow to switch user within CQLSH session - Key: CASSANDRA-7212 URL: https://issues.apache.org/jira/browse/CASSANDRA-7212 Project: Cassandra Issue Type: Improvement Components: API Environment: [cqlsh 4.1.1 | Cassandra 2.0.7.31 | CQL spec 3.1.1 | Thrift protocol 19.39.0] Reporter: Jose Martinez Poblete Labels: cqlsh Once a user is logged into CQLSH, it is not possible to switch to another user without exiting and relaunch This is a feature offered in postgres and probably other databases: http://secure.encivasolutions.com/knowledgebase.php?action=displayarticleid=1126 Perhaps this could be implemented on CQLSH as part of the USE directive: USE Keyspace [USER] [password] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7212) Allow to switch user within CQLSH session
[ https://issues.apache.org/jira/browse/CASSANDRA-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338314#comment-14338314 ] Anuja Mandlecha commented on CASSANDRA-7212: I am taking up this bug and I think the syntax should be USE keyspace [USER] WITH [PASSWORD] wherein the password should be hidden (using asterisks) as in postgres Please let me know your thoughts on this. Allow to switch user within CQLSH session - Key: CASSANDRA-7212 URL: https://issues.apache.org/jira/browse/CASSANDRA-7212 Project: Cassandra Issue Type: Improvement Components: API Environment: [cqlsh 4.1.1 | Cassandra 2.0.7.31 | CQL spec 3.1.1 | Thrift protocol 19.39.0] Reporter: Jose Martinez Poblete Labels: cqlsh Once a user is logged into CQLSH, it is not possible to switch to another user without exiting and relaunch This is a feature offered in postgres and probably other databases: http://secure.encivasolutions.com/knowledgebase.php?action=displayarticleid=1126 Perhaps this could be implemented on CQLSH as part of the USE directive: USE Keyspace [USER] [password] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[
https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333243#comment-14333243
]
Anuja Mandlecha edited comment on CASSANDRA-6538 at 2/23/15 11:54 AM:
--
{quote} As long as BytesType is declared as the type of argument, the type
system ensure it will only be called on that{quote}
This is what is expected, but as per the code in BytesType.java in cassandra
2.1 branch on git as given below:
{code}
public boolean isValueCompatibleWithInternal(AbstractType? otherType)
{
// BytesType can read anything
return true;
}
{code}
true is returned for every standard type (like text,int etc) and the sizeof
calculates size for them,which is contradictory to how we want the sizeof() to
behave. That is why I had introduced the type check in Selection.
was (Author: anuja_mandlecha):
{quote} As long as BytesType is declared as the type of argument, the type
system ensure it will only be called on that{quote}
This is what is expected, but as per the code in BytesType.java as given below:
{code}
public boolean isValueCompatibleWithInternal(AbstractType? otherType)
{
// BytesType can read anything
return true;
}
{code}
true is returned for every standard type (like text,int etc) and the sizeof
calculates size for them,which is contradictory to how we want the sizeof() to
behave. That is why I had introduced the type check in Selection.
Provide a read-time CQL function to display the data size of columns and rows
-
Key: CASSANDRA-6538
URL: https://issues.apache.org/jira/browse/CASSANDRA-6538
Project: Cassandra
Issue Type: Improvement
Reporter: Johnny Miller
Priority: Minor
Labels: cql
Attachments: 6538.patch, CodeSnippet.txt, sizeFzt.PNG
It would be extremely useful to be able to work out the size of rows and
columns via CQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[
https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333243#comment-14333243
]
Anuja Mandlecha commented on CASSANDRA-6538:
{quote} As long as BytesType is declared as the type of argument, the type
system ensure it will only be called on that{quote}
This is what is expected, but as per the code in BytesType.java as given below:
{code}
public boolean isValueCompatibleWithInternal(AbstractType? otherType)
{
// BytesType can read anything
return true;
}
{code}
true is returned for every standard type (like text,int etc) and the sizeof
calculates size for them,which is contradictory to how we want the sizeof() to
behave. That is why I had introduced the type check in Selection.
Provide a read-time CQL function to display the data size of columns and rows
-
Key: CASSANDRA-6538
URL: https://issues.apache.org/jira/browse/CASSANDRA-6538
Project: Cassandra
Issue Type: Improvement
Reporter: Johnny Miller
Priority: Minor
Labels: cql
Attachments: 6538.patch, CodeSnippet.txt, sizeFzt.PNG
It would be extremely useful to be able to work out the size of rows and
columns via CQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5194) LIKE Operator in CQL When Creating Column Families
[
https://issues.apache.org/jira/browse/CASSANDRA-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333189#comment-14333189
]
Anuja Mandlecha commented on CASSANDRA-5194:
This bug is duplicate of 7662 7643.
LIKE Operator in CQL When Creating Column Families
--
Key: CASSANDRA-5194
URL: https://issues.apache.org/jira/browse/CASSANDRA-5194
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.1
Reporter: Russell Bradberry
Priority: Minor
Labels: cql
Some RDBMSs have a very convenient feature that allows to create tables that
look like other tables.
THe end result should look similar to:
{code}
CREATE TABLE foo LIKE bar;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: 6538-v2.patch Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538-v2.patch, 6538.patch, CodeSnippet.txt, sizeFzt.PNG It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334419#comment-14334419 ] Anuja Mandlecha commented on CASSANDRA-6538: Attached the updated patch (6538-v2.patch). Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538-v2.patch, 6538.patch, CodeSnippet.txt, sizeFzt.PNG It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: CodeSnippet.txt Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538.patch, CodeSnippet.txt, sizeFzt.PNG It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[
https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14328895#comment-14328895
]
Anuja Mandlecha commented on CASSANDRA-6538:
I looked into the code and as per you requirement of allowing only blob types
as input to sizeof() we will have to check the datatype of providedArgs against
BytesType which is used for BLOB using the condition
{code}
if(fun.name().equalsIgnoreCase(sizeof)
!args.get(0).getType().equals(BytesType.instance))
throw new InvalidRequestException(String.format(Type
error: %s cannot be passed as argument 0 of function %s of type blob,
args.get(0), fun.name()));
{code}
But as we can see in attached CodeSnippet.txt, to apply the same condition in
validateTpes() where other validations are being done, we need getType() of
providedArgs which we cannot get here since it is an object of class that
implements interface AssignementTestable.
Hence to resolve this there can be two approaches,
1. Add one more argument of type Function to isAssignable() and check for the
functionName and valid types and return value accordingly.
2. Use the if condition before calling validateTypes() (i.e. in makeSelector()
of Selection class)
Note: Approach 1 can result into a lot of code change since the function
declaration is getting changed.
Please let me know your thoughts on this.
Provide a read-time CQL function to display the data size of columns and rows
-
Key: CASSANDRA-6538
URL: https://issues.apache.org/jira/browse/CASSANDRA-6538
Project: Cassandra
Issue Type: Improvement
Reporter: Johnny Miller
Priority: Minor
Labels: cql
Attachments: 6538.patch, sizeFzt.PNG
It would be extremely useful to be able to work out the size of rows and
columns via CQL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: (was: 6538.patch) Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: (was: sizeFzt.PNG) Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: sizeFzt.PNG Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538.patch, sizeFzt.PNG It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: 6538.patch Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538.patch It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14314180#comment-14314180 ] Anuja Mandlecha commented on CASSANDRA-6538: I am taking a step back and reuploading the patch. Now I am considering everything as BLOB(bytebuffer) and the sizeOf() calculates the size for all data types(including standard data types like int,float). But on a second thought I think calculating size of data types like integers, floats etc is of no use since they are fixed and the sizeOf() should only calculate the size for variable length data types like text,BLOB and collection types. Let me know your views and comments on the same. Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538.patch It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312216#comment-14312216 ] Anuja Mandlecha commented on CASSANDRA-6538: I have taken up this bug and introduced a size() to calculate the size of the cell(each row) of the column given as parameter to the function. This function supports all standard and collection types. I am attaching the patch for the same. Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-6538: --- Attachment: sizeFzt.PNG 6538.patch Provide a read-time CQL function to display the data size of columns and rows - Key: CASSANDRA-6538 URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: cql Attachments: 6538.patch, sizeFzt.PNG It would be extremely useful to be able to work out the size of rows and columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8554) Node where gossip is disabled still shows as UP on that node; other nodes show it as DN
[
https://issues.apache.org/jira/browse/CASSANDRA-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301201#comment-14301201
]
Anuja Mandlecha commented on CASSANDRA-8554:
I tried to reproduce the same bug using apache cassandra-2.0.8 which dse-4.5.1
uses but couldnt reproduce. The node is shown as down once it is drained which
is expected behaviour.I also tried with apache cassandra-2.1.2 and the same
happened with it too.
Node where gossip is disabled still shows as UP on that node; other nodes
show it as DN
Key: CASSANDRA-8554
URL: https://issues.apache.org/jira/browse/CASSANDRA-8554
Project: Cassandra
Issue Type: Bug
Environment: Centos 6.5, DSE4.5.1 tarball install
Reporter: Mark Curtis
Priority: Minor
When running nodetool drain, the drained node will still show the status of
itself as UP in nodetool status even after the drain has finished. For
example using a 3 node cluster on one of the nodes that is still operating
and not drained we see this:
{code}
$ ./dse-4.5.1/bin/nodetool status
Note: Ownership information does not include topology; for complete
information, specify a keyspace
Datacenter: Central
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns Host ID
Rack
UN 192.168.56.21 210.78 KB 256 32.1%
82eb2fca-4f57-467b-a972-93096ec5d69f RAC1
DN 192.168.56.23 2.22 GB256 33.5%
a11bfac1-fad0-440b-bd68-7562a89ce3c7 RAC1
UN 192.168.56.22 2.22 GB256 34.4%
4250cb05-97be-4bac-887a-acc307d1bc0c RAC1
{code}
While on the drained node we see this:
{code}
[datastax@DSE4 ~]$ ./dse-4.5.1/bin/nodetool drain
[datastax@DSE4 ~]$ ./dse-4.5.1/bin/nodetool status
Note: Ownership information does not include topology; for complete
information, specify a keyspace
Datacenter: Central
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns Host ID
Rack
UN 192.168.56.21 210.78 KB 256 32.1%
82eb2fca-4f57-467b-a972-93096ec5d69f RAC1
UN 192.168.56.23 2.22 GB256 33.5%
a11bfac1-fad0-440b-bd68-7562a89ce3c7 RAC1
UN 192.168.56.22 2.22 GB256 34.4%
4250cb05-97be-4bac-887a-acc307d1bc0c RAC1
{code}
Netstat shows outgoing connections from the drained node to other nodes as
still established on port 7000 but the node is no longer listening on port
7000 which I believe is expected.
However the output of nodetool status on the drained node could be
interpreted as misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuja Mandlecha updated CASSANDRA-7950: --- Attachment: 7950.patch [~eugenstud]: I looked into how column command in unix works and did the same for compactionhistory command and also added TAB (\t) as a delimeter for now which can be used by grep, cut,awk commands. In future we can also provide a delimeter option as I have mentioned earlier. For compactionstats the code is already present to calculate the maxColumnLength, hence I only added a delimeter TAB(\t) to it. The attached path contain these changes. Note: I have used cassandra 2.1 branch. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.13 Attachments: 7950.patch, nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288820#comment-14288820 ] Anuja Mandlecha commented on CASSANDRA-7950: @Brandon: We will have to definitely add a delimeter option (-- delimeter )to the nodetool command wherein the output will be displayed seperated by that delimiter and on which cut,grep etc commands can work. @Eugene: That looks like a good option. Will need to investigate more on this. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.13 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288820#comment-14288820 ] Anuja Mandlecha edited comment on CASSANDRA-7950 at 1/23/15 6:03 AM: - [~brandon.williams]: We will have to definitely add a delimeter option (-- delimeter )to the nodetool command wherein the output will be displayed seperated by that delimiter and on which cut,grep etc commands can work. [~aechttpd]: That looks like a good option. Will need to investigate more on this. was (Author: anuja_mandlecha): @Brandon: We will have to definitely add a delimeter option (-- delimeter )to the nodetool command wherein the output will be displayed seperated by that delimiter and on which cut,grep etc commands can work. @Eugene: That looks like a good option. Will need to investigate more on this. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.13 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283576#comment-14283576 ] Anuja Mandlecha commented on CASSANDRA-7950: I am taking up this bug. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.12 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283760#comment-14283760 ] Anuja Mandlecha commented on CASSANDRA-7950: Hello, There are few points to be considered here: 1. The max char limit for a keyspace and cf name in CQL is 48 chars each. 2. the format specifiers mentioned in nodetool compactionhistory output in code is having 19 chars for keyspace and 29 chars for cfname (%-19s%-29s). Similar is the case with compactionstats command. Hence if the keyspace or cfnames exceed above these limits, there will not be any space between it's value and the next column value. To resolve this issue, we can have two approaches: 1. Keep existing format specifiers and add a tab after each column. 2. Remove existing format specifiers and display complete column values with only seperated by tab. I would suggest approach 1 so as to maintain human readability and make the output parsable. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.12 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8493) nodetool options parsing doesn't allow -h hostname to be at the end anymore
[
https://issues.apache.org/jira/browse/CASSANDRA-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280119#comment-14280119
]
Anuja Mandlecha commented on CASSANDRA-8493:
I fired simple $ ./nodetool command using cassandra 2.1.2 and it gave me
following console output:
user@ubuntu-vm:~/apache-cassandra-2.1.2/bin$ ./nodetool
usage: nodetool [(-u username | --username username)]
[(-pw password | --password password)] [(-h host | --host host)]
[(-p port | --port port)]
[(-pwf passwordFilePath | --password-file passwordFilePath)]
command
[args]
The most commonly used nodetool commands are:
So according to the usage, the command (ring in your example) should always
come at the end as:
$ ./nodetool -h 127.0.0.1 ring
nodetool options parsing doesn't allow -h hostname to be at the end anymore
--
Key: CASSANDRA-8493
URL: https://issues.apache.org/jira/browse/CASSANDRA-8493
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Jeremiah Jordan
Priority: Minor
This used to work:
{noformat}
$ ./nodetool ring -h 127.0.0.1
Error: The keyspace 127.0.0.1, does not exist
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
