[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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)
at
[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-tabpanelfocusedCommentId=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.init(SimpleSliceReader.java:57)
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(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
[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-tabpanelfocusedCommentId=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 CassandraDaemon.java (line 187)
Exception in thread
[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-tabpanelfocusedCommentId=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 Chow
Assignee: Michael Shuler
I am developing a
