[ 
https://issues.apache.org/jira/browse/CASSANDRA-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231649#comment-15231649
 ] 

Mattias W edited comment on CASSANDRA-11528 at 4/8/16 5:15 AM:
---------------------------------------------------------------

I get strange behaviour also on smaller and much more normal tables. For example
{noformat}
SELECT COUNT(*) FROM usr WHERE disabled = true LIMIT 100 ALLOW FILTERING;
{noformat}
works fine from within devcenter

but the next one, which hits many more rows, temporarily makes the server 
unavailable, and reports "Unable to execute CQL script on 'connection1': 
Cassandra failure during read query at consistency ONE (1 responses were 
required but only 0 replica responded, 1 failed". This error message is the 
same as above, except that the server doesn't die.

{noformat}
SELECT COUNT(*) FROM usr WHERE disabled = null LIMIT 100 ALLOW FILTERING;
{noformat}



was (Author: mattiasw2):
I get strange behaviour also on smaller and much more normal tables. For example

{{SELECT COUNT(*) FROM usr WHERE disabled = true LIMIT 100 ALLOW FILTERING;}}

works fine from within devcenter

but the next one, which hits many more rows, temporarily makes the server 
unavailable, and reports "Unable to execute CQL script on 'connection1': 
Cassandra failure during read query at consistency ONE (1 responses were 
required but only 0 replica responded, 1 failed". This error message is the 
same as above, except that the server doesn't die.

{{SELECT COUNT(*) FROM usr WHERE disabled = null LIMIT 100 ALLOW FILTERING;}}


> Server Crash when select returns more than a few hundred rows
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-11528
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11528
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: windows 7, 8 GB machine
>            Reporter: Mattias W
>             Fix For: 3.3
>
>         Attachments: datastax_ddc_server-stdout.2016-04-07.log
>
>
> While implementing a dump procedure, which did "select * from" from one table 
> at a row, I instantly kill the server. A simple "select count(*) from"  also 
> kills it. For a while, I thought the size of blobs were the cause
> I also try to only have a unique id as partition key, I was afraid a single 
> partition got too big or so, but that didn't change anything
> It happens every time, both from Java/Clojure and from DevCenter.
> I looked at the logs at C:\Program Files\DataStax-DDC\logs, but the crash is 
> so quick, so nothing is recorded there.
> There is a Java-out-of-memory in the logs, but that isn't from the time of 
> the crash.
> It only happens for one table, it only has 15000 entries, but there are blobs 
> and byte[] stored there, size between 100kb - 4Mb. Total size for that table 
> is about 6.5 GB on disk.
> I made a workaround by doing many small selects instead, each only fetching 
> 100 rows.
> Is there a setting a can set to make the system log more eagerly, in order to 
> at least get a stacktrace or similar, that might help you.
> It is the prun_srv that dies. Restarting the NT service makes Cassandra run 
> again



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to