[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003915#comment-14003915 ] Vladimir Kuptsov edited comment on CASSANDRA-6525 at 5/20/14 8:18 PM: -- We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: {code} ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : {code} For the node, on which this messages started, we found several messages like on the other nodes {code} INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN {code} and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. was (Author: vkuptcov): We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: {code} ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : {code} For the node, on which this messages started, we found several messages like {code} INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN {code} and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Chow >Assignee: Tyler Hobbs > Fix For: 2.0.8 > > Attachments: 6525-2.0.txt, 6981_test.py > > > I am developing a system on my single machine using VMware Player with 1GB > Ram and 1Gb HHD. When I select all data, I didn't have any problems. But when > I using "WHERE" and it has just below 10 records. I have got this error in > system log: > {noformat} > ERROR [ReadStage:41] 2013-12-25 18:52:11,913 CassandraDaemon.java (line 187) > Exception in thread Thread[ReadStage:41,5,main] > java.io.IOError: java.io.EOFException > at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) > at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) >
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003915#comment-14003915 ] Vladimir Kuptsov edited comment on CASSANDRA-6525 at 5/20/14 8:16 PM: -- We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. was (Author: vkuptcov): We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: [code] ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : [/code] For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Chow >Assignee: Tyler Hobbs > Fix For: 2.0.8 > > Attachments: 6525-2.0.txt, 6981_test.py > > > I am developing a system on my single machine using VMware Player with 1GB > Ram and 1Gb HHD. When I select all data, I didn't have any problems. But when > I using "WHERE" and it has just below 10 records. I have got this error in > system log: > {noformat} > ERROR [ReadStage:41] 2013-12-25 18:52:11,913 CassandraDaemon.java (line 187) > Exception in thread Thread[ReadStage:41,5,main] > java.io.IOError: java.io.EOFException > at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) > at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) > at > org.apache.cassandra.db.columniterator.SimpleSl
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003915#comment-14003915 ] Vladimir Kuptsov edited comment on CASSANDRA-6525 at 5/20/14 8:18 PM: -- We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: {code} ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : {code} For the node, on which this messages started, we found several messages like {code} INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN {code} and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. was (Author: vkuptcov): We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: {code} ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : {code} For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Chow >Assignee: Tyler Hobbs > Fix For: 2.0.8 > > Attachments: 6525-2.0.txt, 6981_test.py > > > I am developing a system on my single machine using VMware Player with 1GB > Ram and 1Gb HHD. When I select all data, I didn't have any problems. But when > I using "WHERE" and it has just below 10 records. I have got this error in > system log: > {noformat} > ERROR [ReadStage:41] 2013-12-25 18:52:11,913 CassandraDaemon.java (line 187) > Exception in thread Thread[ReadStage:41,5,main] > java.io.IOError: java.io.EOFException > at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) > at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) > at > org.apache.cassandra.db.
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003915#comment-14003915 ] Vladimir Kuptsov edited comment on CASSANDRA-6525 at 5/20/14 8:17 PM: -- We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: {code} ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : {code} For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. was (Author: vkuptcov): We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Chow >Assignee: Tyler Hobbs > Fix For: 2.0.8 > > Attachments: 6525-2.0.txt, 6981_test.py > > > I am developing a system on my single machine using VMware Player with 1GB > Ram and 1Gb HHD. When I select all data, I didn't have any problems. But when > I using "WHERE" and it has just below 10 records. I have got this error in > system log: > {noformat} > ERROR [ReadStage:41] 2013-12-25 18:52:11,913 CassandraDaemon.java (line 187) > Exception in thread Thread[ReadStage:41,5,main] > java.io.IOError: java.io.EOFException > at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) > at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) > at > org.apache.cassandra.db.columniterator.SimpleSl
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003915#comment-14003915 ] Vladimir Kuptsov edited comment on CASSANDRA-6525 at 5/20/14 8:16 PM: -- We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: [code] ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : [/code] For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. was (Author: vkuptcov): We have a cluster with 5 nodes in one DC and a cluster with two nodes in the other without a replication between these datacenters. In all DC we use C* 2.0.5. Today we've found a bug with similar messages but with the different result. We have dropped and recreated one table in the DC with 5 nodes and just truncated the same table in another DC. After ~10 hours we have noticed appearing of the following messages in the first DC logs: ``` ERROR [ReadStage:231469] 2014-05-20 21:05:20,349 CassandraDaemon.java (line 192) Exception in thread Thread[ReadStage:231469,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88) : ```. For the node, on which this messages started, we found several messages like " INFO [GossipTasks:1] 2014-05-20 21:20:31,864 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN INFO [RequestResponseStage:10] 2014-05-20 21:20:32,186 Gossiper.java (line 849) InetAddress /10.33.20.91 is now UP INFO [GossipTasks:1] 2014-05-20 21:26:51,965 Gossiper.java (line 863) InetAddress /10.33.20.91 is now DOWN " and finally the node has stopped. We found such effect only in the DC, where we have dropped and recreated table. In the DC with truncate everything is OK. > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Chow >Assignee: Tyler Hobbs > Fix For: 2.0.8 > > Attachments: 6525-2.0.txt, 6981_test.py > > > I am developing a system on my single machine using VMware Player with 1GB > Ram and 1Gb HHD. When I select all data, I didn't have any problems. But when > I using "WHERE" and it has just below 10 records. I have got this error in > system log: > {noformat} > ERROR [ReadStage:41] 2013-12-25 18:52:11,913 CassandraDaemon.java (line 187) > Exception in thread Thread[ReadStage:41,5,main] > java.io.IOError: java.io.EOFException > at org.apache.cassandra.db.Column$1.computeNext(Column.java:79) > at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) > at > org.apache.cassandra.db.columniterator.Si
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967092#comment-13967092 ] Ryan McGuire edited comment on CASSANDRA-6525 at 4/11/14 8:59 PM: -- fwiw, I've written a multi-threaded test for this using the python-driver. It's attached above as 6981_test.py. I used the criteria stated in CASSANDRA-6981: bq. created about 16 tables, all the same, each with about 5 text fields and 5 binary fields. Most of those fields had a secondary index. Then insert into all the tables in parallel. I'm using 16 tables, each with 5 text fields, 5 blob fields, inserting 10,000 rows into each table in parallel, and then selecting that data out based on a single field (blob5) that has 5 diffent options. I could not reproduce the error in this ticket, however I did get this error several times: {code} ERROR [ReadStage:136] 2014-04-11 16:55:36,312 CassandraDaemon.java (line 198) Exception in thread Thread[ReadStage:136,5,main] java.lang.RuntimeException: java.lang.NullPointerException at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1920) 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) Caused by: java.lang.NullPointerException at org.apache.cassandra.io.util.RandomAccessReader.getTotalBufferSize(RandomAccessReader.java:157) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.getTotalBufferSize(CompressedRandomAccessReader.java:159) at org.apache.cassandra.service.FileCacheService.get(FileCacheService.java:96) at org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:36) at org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1195) at org.apache.cassandra.db.columniterator.SimpleSliceReader.(SimpleSliceReader.java:57) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:42) at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:167) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:250) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1540) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1369) at org.apache.cassandra.db.index.composites.CompositesSearcher$1.computeNext(CompositesSearcher.java:260) at org.apache.cassandra.db.index.composites.CompositesSearcher$1.computeNext(CompositesSearcher.java:103) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1735) at org.apache.cassandra.db.index.composites.CompositesSearcher.search(CompositesSearcher.java:50) at org.apache.cassandra.db.index.SecondaryIndexManager.search(SecondaryIndexManager.java:556) at org.apache.cassandra.db.ColumnFamilyStore.search(ColumnFamilyStore.java:1723) at org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:135) at org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1374) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1916) ... 3 more {code} was (Author: enigmacurry): fwiw, I've written a multi-threaded test for this using the python-driver. I used the criteria stated in CASSANDRA-6981: bq. created about 16 tables, all the same, each with about 5 text fields and 5 binary fields. Most of those fields had a secondary index. Then insert into all the tables in parallel. I'm using 16 tables, each with 5 text fields, 5 blob fields, inserting 10,000 rows into each table in parallel, and then selecting that data out based on a single field (blob5) that has 5 diffent options. I could not reproduce the error in this ticket, however I did get this error several times: {code} ERROR [ReadStage:136] 2014-04-11 16:55:36,312 CassandraDaemon.java (line 198) Exception in thread Thread[ReadStage:136,5,main] java.lang.RuntimeException: java.lang.NullPointerException at org.apache.c
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935623#comment-13935623 ] Michael Shuler edited comment on CASSANDRA-6525 at 3/15/14 12:46 AM: - I tested using cassandra-2.0 git branch on my laptop (16G), which ran fine. I tried on a 4G box and 2G box - both ran fine looping through the script below, while running cassandra-stress in another shell, also. I'm about 10 or so loops through, while looping stress read and write on a 1G virtualbox vm, and it's slow, but I've had no errors, so far. I'll let it keep running a while to see if I can get a timeout or error of some sort *update* 2.5 hours of looping this while looping stress read/write on my vbox vm and all is well. *update2* tried the same after dropping my vbox vm to 512M - 45k row load takes about 60 sec. to import and the read takes a little longer to output - vm starts swapping on the 45k read and the load avg nears 40, but it's still working. {code} #!/bin/sh # create some data: for i in $(seq 1 50); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_1-50.csv ; done for i in $(seq 51 500); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_51-500.csv ; done for i in $(seq 501 5000); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_501-5000.csv ; done for i in $(seq 5001 5); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_5001-5.csv ; done # create our cql to drop/create/import cat << 'EOF' > c6525_run.cql DROP KEYSPACE c6525; CREATE KEYSPACE c6525 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE TABLE c6525.test (hidden text, field2 text, field3 text, field4 text, PRIMARY KEY (hidden, field2, field3)); COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_1-50.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_51-500.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_501-5000.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_5001-5.csv'; SELECT * from c6525.test WHERE hidden = 'N' LIMIT 51000; EOF echo; echo "*** Hit CTL-C to stop looping..***"; echo sleep 3 # loop it while true; do echo "SOURCE 'c6525_run.cql';" | cqlsh ; sleep 1 ; done {code} was (Author: mshuler): I tested using cassandra-2.0 git branch on my laptop (16G), which ran fine. I tried on a 4G box and 2G box - both ran fine looping through the script below, while running cassandra-stress in another shell, also. I'm about 10 or so loops through, while looping stress read and write on a 1G virtualbox vm, and it's slow, but I've had no errors, so far. I'll let it keep running a while to see if I can get a timeout or error of some sort *update* 2.5 hours of looping this while looping stress read/write on my vbox vm and all is well. {code} #!/bin/sh # create some data: for i in $(seq 1 50); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_1-50.csv ; done for i in $(seq 51 500); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_51-500.csv ; done for i in $(seq 501 5000); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_501-5000.csv ; done for i in $(seq 5001 5); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_5001-5.csv ; done # create our cql to drop/create/import cat << 'EOF' > c6525_run.cql DROP KEYSPACE c6525; CREATE KEYSPACE c6525 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE TABLE c6525.test (hidden text, field2 text, field3 text, field4 text, PRIMARY KEY (hidden, field2, field3)); COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_1-50.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_51-500.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_501-5000.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_5001-5.csv'; SELECT * from c6525.test WHERE hidden = 'N' LIMIT 51000; EOF echo; echo "*** Hit CTL-C to stop looping..***"; echo sleep 3 # loop it while true; do echo "SOURCE 'c6525_run.cql';" | cqlsh ; sleep 1 ; done {code} > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Ch
[jira] [Comment Edited] (CASSANDRA-6525) Cannot select data which using "WHERE"
[ https://issues.apache.org/jira/browse/CASSANDRA-6525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935623#comment-13935623 ] Michael Shuler edited comment on CASSANDRA-6525 at 3/14/14 11:29 PM: - I tested using cassandra-2.0 git branch on my laptop (16G), which ran fine. I tried on a 4G box and 2G box - both ran fine looping through the script below, while running cassandra-stress in another shell, also. I'm about 10 or so loops through, while looping stress read and write on a 1G virtualbox vm, and it's slow, but I've had no errors, so far. I'll let it keep running a while to see if I can get a timeout or error of some sort *update* 2.5 hours of looping this while looping stress read/write on my vbox vm and all is well. {code} #!/bin/sh # create some data: for i in $(seq 1 50); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_1-50.csv ; done for i in $(seq 51 500); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_51-500.csv ; done for i in $(seq 501 5000); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_501-5000.csv ; done for i in $(seq 5001 5); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_5001-5.csv ; done # create our cql to drop/create/import cat << 'EOF' > c6525_run.cql DROP KEYSPACE c6525; CREATE KEYSPACE c6525 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE TABLE c6525.test (hidden text, field2 text, field3 text, field4 text, PRIMARY KEY (hidden, field2, field3)); COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_1-50.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_51-500.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_501-5000.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_5001-5.csv'; SELECT * from c6525.test WHERE hidden = 'N' LIMIT 51000; EOF echo; echo "*** Hit CTL-C to stop looping..***"; echo sleep 3 # loop it while true; do echo "SOURCE 'c6525_run.cql';" | cqlsh ; sleep 1 ; done {code} was (Author: mshuler): I tested using cassandra-2.0 git branch on my laptop (16G), which ran fine. I tried on a 4G box and 2G box - both ran fine looping through the script below, while running cassandra-stress in another shell, also. I'm about 10 or so loops through, while looping stress read and write on a 1G virtualbox vm, and it's slow, but I've had no errors, so far. I'll let it keep running a while to see if I can get a timeout or error of some sort {code} #!/bin/sh # create some data: for i in $(seq 1 50); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_1-50.csv ; done for i in $(seq 51 500); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_51-500.csv ; done for i in $(seq 501 5000); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_501-5000.csv ; done for i in $(seq 5001 5); do echo "N,text blah blah$i,text blah blah$i,text blah blah$i" >> c6525_5001-5.csv ; done # create our cql to drop/create/import cat << 'EOF' > c6525_run.cql DROP KEYSPACE c6525; CREATE KEYSPACE c6525 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE TABLE c6525.test (hidden text, field2 text, field3 text, field4 text, PRIMARY KEY (hidden, field2, field3)); COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_1-50.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_51-500.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_501-5000.csv'; SELECT * from c6525.test WHERE hidden = 'N'; COPY c6525.test (hidden, field2, field3, field4) FROM 'c6525_5001-5.csv'; SELECT * from c6525.test WHERE hidden = 'N' LIMIT 51000; EOF echo; echo "*** Hit CTL-C to stop looping..***"; echo sleep 3 # loop it while true; do echo "SOURCE 'c6525_run.cql';" | cqlsh ; sleep 1 ; done {code} > Cannot select data which using "WHERE" > -- > > Key: CASSANDRA-6525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6525 > Project: Cassandra > Issue Type: Bug > Environment: Linux RHEL5 > RAM: 1GB > Cassandra 2.0.3 > CQL spec 3.1.1 > Thrift protocol 19.38.0 >Reporter: Silence Chow >Assignee: Michael Shuler > > I am developing a system on my single machine using VMware Player with 1GB > Ram and 1Gb HHD. When I select all data, I didn't have any problems. But when > I using "WHERE" and it has just below 10 records. I have got this error in > system log: > ERROR [ReadStage:41] 2013-12-25 18:52:11,913