[jira] [Commented] (CASSANDRA-10587) sstablemetadata NPE on cassandra 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-10587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15150067#comment-15150067
]
Roman Skvazh commented on CASSANDRA-10587:
--
[~yukim], yeah, with absolute path it works! Thanks.
> sstablemetadata NPE on cassandra 2.2
>
>
> Key: CASSANDRA-10587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Tiago Batista
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.2.x, 3.x
>
>
> I have recently upgraded my cassandra cluster to 2.2, currently running
> 2.2.3. After running the first repair, cassandra renames the sstables to the
> new naming schema that does not contain the keyspace name.
> This causes sstablemetadata to fail with the following stack trace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:275)
> at
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
> at
> org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10587) sstablemetadata NPE on cassandra 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-10587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148877#comment-15148877
]
Roman Skvazh edited comment on CASSANDRA-10587 at 2/16/16 4:47 PM:
---
Same problem here on 2.2.5 after upgrading from 2.1.13 on all nodes on new
upgraded "short-named"-files.
{noformat}
Exception in thread "main" java.lang.NullPointerException
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:271)
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
at
org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
{noformat}
was (Author: rskvazh):
Same problem here on 2.2.5 after upgrading from 2.1.13 on all nodes.
{noformat}
Exception in thread "main" java.lang.NullPointerException
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:271)
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
at
org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
{noformat}
> sstablemetadata NPE on cassandra 2.2
>
>
> Key: CASSANDRA-10587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Tiago Batista
>Assignee: Paulo Motta
> Fix For: 2.2.x, 3.x
>
>
> I have recently upgraded my cassandra cluster to 2.2, currently running
> 2.2.3. After running the first repair, cassandra renames the sstables to the
> new naming schema that does not contain the keyspace name.
> This causes sstablemetadata to fail with the following stack trace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:275)
> at
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
> at
> org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10587) sstablemetadata NPE on cassandra 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-10587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148877#comment-15148877
]
Roman Skvazh commented on CASSANDRA-10587:
--
Same problem here on 2.2.5 after upgrading from 2.1.13 on all nodes.
{noformat}
Exception in thread "main" java.lang.NullPointerException
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:271)
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
at
org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
{noformat}
> sstablemetadata NPE on cassandra 2.2
>
>
> Key: CASSANDRA-10587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Tiago Batista
>Assignee: Paulo Motta
> Fix For: 2.2.x, 3.x
>
>
> I have recently upgraded my cassandra cluster to 2.2, currently running
> 2.2.3. After running the first repair, cassandra renames the sstables to the
> new naming schema that does not contain the keyspace name.
> This causes sstablemetadata to fail with the following stack trace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:275)
> at
> org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:172)
> at
> org.apache.cassandra.tools.SSTableMetadataViewer.main(SSTableMetadataViewer.java:52)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Skvazh updated CASSANDRA-6698: Reproduced In: 2.0.5, 2.0.4 (was: 2.0.5) Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6698) Many too small SSTables when full repair
Roman Skvazh created CASSANDRA-6698: --- Summary: Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899737#comment-13899737 ] Roman Skvazh edited comment on CASSANDRA-6698 at 2/12/14 11:11 PM: --- Some of files in attached file was (Author: rskvazh): Some of files Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical Attachments: cassa-many-small-sstables.txt We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Skvazh updated CASSANDRA-6698: Attachment: cassa-many-small-sstables.txt Some of files Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical Attachments: cassa-many-small-sstables.txt We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Skvazh updated CASSANDRA-6698: Description: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 165Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( was: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical Attachments: cassa-many-small-sstables.txt We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 165Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Skvazh updated CASSANDRA-6698: Description: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( was: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical Attachments: cassa-many-small-sstables.txt We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Skvazh updated CASSANDRA-6698: Description: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( was: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 165Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical Attachments: cassa-many-small-sstables.txt We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Skvazh updated CASSANDRA-6698: Description: We have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( was: We are have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Bug Reporter: Roman Skvazh Priority: Critical Attachments: cassa-many-small-sstables.txt We have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6698) Many too small SSTables when full repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899769#comment-13899769 ] Roman Skvazh commented on CASSANDRA-6698: - We can not use STCS because we have wide-rows and heavy inserts/deletes Many too small SSTables when full repair Key: CASSANDRA-6698 URL: https://issues.apache.org/jira/browse/CASSANDRA-6698 Project: Cassandra Issue Type: Improvement Reporter: Roman Skvazh Priority: Minor Attachments: cassa-many-small-sstables.txt We have troubles when cassandra drops messages because there is too many (over 10,000 on one column family) small (from 1Kb to 200Kb, and normal sizes too) and many pending compactions (over 700). We are using Leveled compaction with 160Mb sstable size. PS. Temp fix: stop repair, disable thrift,gossip and wait for compactions to be finished. Because this, we can not run full repair for about a month :( -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6629) Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
[
https://issues.apache.org/jira/browse/CASSANDRA-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885183#comment-13885183
]
Roman Skvazh commented on CASSANDRA-6629:
-
Guys, what about scrub and read repair problem?
Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
Key: CASSANDRA-6629
URL: https://issues.apache.org/jira/browse/CASSANDRA-6629
Project: Cassandra
Issue Type: Bug
Components: API
Environment: 15 nodes, 2.0.4, RF=3
Reporter: Roman Skvazh
Assignee: Mikhail Stepura
Fix For: 1.2.14, 2.0.5
Attachments: CASSANDRA-1.2-6629-v2.patch, CASSANDRA-2.0-6629-v2.patch
I've got this error in system.log on all coordinators
{noformat}
ERROR [Thrift:37555] 2014-01-28 19:53:51,547 CustomTThreadPoolServer.java
(line 212) Error occurred during processing of message.
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:400)
at java.util.ArrayList.remove(ArrayList.java:477)
at
org.apache.cassandra.db.ArrayBackedSortedColumns$ReverseSortedCollection$1.remove(ArrayBackedSortedColumns.java:373)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:249)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1370)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1189)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:188)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:163)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:58)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:212)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
It's occurred on coordinator (not always primary or secondary of this uid-PK)
when I execute query (PHP or Python client got TSocket read 0 bytes
exception):
{code:sql}SELECT * FROM home_timeline WHERE uid = 0x52dcbc794989a6ea2c8b4569
ORDER BY tuuid DESC LIMIT 32{code}
If limit 32, then its ok. When ORDER ... ASC its ok. When ConsistencyLevel
1 its ok.
On one node data is inconsistent with two others, and read repair won't work
(32-nd element is odd).
Our RF = 3
Cassandra version 2.0.4
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CASSANDRA-6629) Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
Roman Skvazh created CASSANDRA-6629:
---
Summary: Coordinator's java.lang.ArrayIndexOutOfBoundsException:
-1 with CL 1
Key: CASSANDRA-6629
URL: https://issues.apache.org/jira/browse/CASSANDRA-6629
Project: Cassandra
Issue Type: Bug
Environment: 15 nodes, 2.0.4, RF=3
Reporter: Roman Skvazh
I've got this error in system.log on all coordinators
{noformat}
ERROR [Thrift:37555] 2014-01-28 19:53:51,547 CustomTThreadPoolServer.java (line
212) Error occurred during processing of message.
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:400)
at java.util.ArrayList.remove(ArrayList.java:477)
at
org.apache.cassandra.db.ArrayBackedSortedColumns$ReverseSortedCollection$1.remove(ArrayBackedSortedColumns.java:373)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:249)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1370)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1189)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:188)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:163)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:58)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:212)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
It's occurred on coordinator (not always primary or secondary of this uid-PK)
when I execute query (PHP or Python client got TSocket read 0 bytes
exception):
{code:sql}SELECT * FROM home_timeline WHERE uid = 0x52dcbc794989a6ea2c8b4569
ORDER BY tuuid DESC LIMIT 32{code}
If limit 32, then its ok. When ORDER ... ASC its ok. When ConsistencyLevel 1
its ok.
On one node data is inconsistent with two others, and read repair won't work
(32-nd element is odd).
Our RF = 3
Cassandra version 2.0.4
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6629) Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
[
https://issues.apache.org/jira/browse/CASSANDRA-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884560#comment-13884560
]
Roman Skvazh commented on CASSANDRA-6629:
-
Does this linked with CASSANDRA-6333?
Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
Key: CASSANDRA-6629
URL: https://issues.apache.org/jira/browse/CASSANDRA-6629
Project: Cassandra
Issue Type: Bug
Environment: 15 nodes, 2.0.4, RF=3
Reporter: Roman Skvazh
I've got this error in system.log on all coordinators
{noformat}
ERROR [Thrift:37555] 2014-01-28 19:53:51,547 CustomTThreadPoolServer.java
(line 212) Error occurred during processing of message.
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:400)
at java.util.ArrayList.remove(ArrayList.java:477)
at
org.apache.cassandra.db.ArrayBackedSortedColumns$ReverseSortedCollection$1.remove(ArrayBackedSortedColumns.java:373)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:249)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1370)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1189)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:188)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:163)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:58)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:212)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
It's occurred on coordinator (not always primary or secondary of this uid-PK)
when I execute query (PHP or Python client got TSocket read 0 bytes
exception):
{code:sql}SELECT * FROM home_timeline WHERE uid = 0x52dcbc794989a6ea2c8b4569
ORDER BY tuuid DESC LIMIT 32{code}
If limit 32, then its ok. When ORDER ... ASC its ok. When ConsistencyLevel
1 its ok.
On one node data is inconsistent with two others, and read repair won't work
(32-nd element is odd).
Our RF = 3
Cassandra version 2.0.4
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6629) Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
[
https://issues.apache.org/jira/browse/CASSANDRA-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884743#comment-13884743
]
Roman Skvazh commented on CASSANDRA-6629:
-
Does this fix (idx--) solve problem with read repair?
Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
Key: CASSANDRA-6629
URL: https://issues.apache.org/jira/browse/CASSANDRA-6629
Project: Cassandra
Issue Type: Bug
Components: API
Environment: 15 nodes, 2.0.4, RF=3
Reporter: Roman Skvazh
Assignee: Mikhail Stepura
Fix For: 2.0.5
I've got this error in system.log on all coordinators
{noformat}
ERROR [Thrift:37555] 2014-01-28 19:53:51,547 CustomTThreadPoolServer.java
(line 212) Error occurred during processing of message.
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:400)
at java.util.ArrayList.remove(ArrayList.java:477)
at
org.apache.cassandra.db.ArrayBackedSortedColumns$ReverseSortedCollection$1.remove(ArrayBackedSortedColumns.java:373)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:249)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1370)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1189)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:188)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:163)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:58)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:212)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
It's occurred on coordinator (not always primary or secondary of this uid-PK)
when I execute query (PHP or Python client got TSocket read 0 bytes
exception):
{code:sql}SELECT * FROM home_timeline WHERE uid = 0x52dcbc794989a6ea2c8b4569
ORDER BY tuuid DESC LIMIT 32{code}
If limit 32, then its ok. When ORDER ... ASC its ok. When ConsistencyLevel
1 its ok.
On one node data is inconsistent with two others, and read repair won't work
(32-nd element is odd).
Our RF = 3
Cassandra version 2.0.4
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6629) Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
[
https://issues.apache.org/jira/browse/CASSANDRA-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884775#comment-13884775
]
Roman Skvazh commented on CASSANDRA-6629:
-
Wow. It seems nodetool scrub on node with odd row helped to me. Read repair
restore that 32-nd row on other replicas, this CQL query worked properly and
without exception now...
Coordinator's java.lang.ArrayIndexOutOfBoundsException: -1 with CL 1
Key: CASSANDRA-6629
URL: https://issues.apache.org/jira/browse/CASSANDRA-6629
Project: Cassandra
Issue Type: Bug
Components: API
Environment: 15 nodes, 2.0.4, RF=3
Reporter: Roman Skvazh
Assignee: Mikhail Stepura
Fix For: 2.0.5
I've got this error in system.log on all coordinators
{noformat}
ERROR [Thrift:37555] 2014-01-28 19:53:51,547 CustomTThreadPoolServer.java
(line 212) Error occurred during processing of message.
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:400)
at java.util.ArrayList.remove(ArrayList.java:477)
at
org.apache.cassandra.db.ArrayBackedSortedColumns$ReverseSortedCollection$1.remove(ArrayBackedSortedColumns.java:373)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:249)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1370)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1189)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:188)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:163)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:58)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:212)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
It's occurred on coordinator (not always primary or secondary of this uid-PK)
when I execute query (PHP or Python client got TSocket read 0 bytes
exception):
{code:sql}SELECT * FROM home_timeline WHERE uid = 0x52dcbc794989a6ea2c8b4569
ORDER BY tuuid DESC LIMIT 32{code}
If limit 32, then its ok. When ORDER ... ASC its ok. When ConsistencyLevel
1 its ok.
On one node data is inconsistent with two others, and read repair won't work
(32-nd element is odd).
Our RF = 3
Cassandra version 2.0.4
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6055) 'Bad Request: Invalid null value for partition key part' on SELECT .. WHERE key IN (val,NULL)
[ https://issues.apache.org/jira/browse/CASSANDRA-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13787994#comment-13787994 ] Roman Skvazh commented on CASSANDRA-6055: - I agree with Sylvain Lebresne. CQL is not SQL and there is no need for this hack (ignore NULL values in queries). 'Bad Request: Invalid null value for partition key part' on SELECT .. WHERE key IN (val,NULL) - Key: CASSANDRA-6055 URL: https://issues.apache.org/jira/browse/CASSANDRA-6055 Project: Cassandra Issue Type: Bug Environment: cqlsh, pdo_cassandra Reporter: Sergey Nagaytsev Priority: Minor Labels: cql3 Query: SELECT * FROM user WHERE key IN(uuid,NULL); Table: CREATE COLUMNFAMILY user ( KEY uuid PRIMARY KEY, name text, note text, avatar text, email text, phone text, login text, pw text, st text ); Logs: Nothing, last message hours ago. This query is good in SQL and so is generated by DB abstraction library. Fix on applications sides is multiplying of work. -- This message was sent by Atlassian JIRA (v6.1#6144)
