[
https://issues.apache.org/jira/browse/CASSANDRA-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777628#comment-13777628
]
Ngoc Minh Vo commented on CASSANDRA-6004:
-----------------------------------------
Hello,
I've deployed the new version v2.0.1 but it seems that the bug is not fixed.
Here is how to reproduce the bug:
{code}
CREATE TABLE pdl_identity (
id text, -- PDL identity (concatenation of
execution_id, result index, portfolio index)
date int, -- cob_date (in YYYYMMDD format)
portfolio text, -- portfolio_identifier in pricing
output (stored in lowercase)
parent_id text, -- PDL identity of parent (null for
root ones)
result_id text, -- pricing result ID (eg. prism_prs_1,
prism_prs_2,...)
kind text, -- pdl_kind (eg. shift_1%, shift_3%,
api_reflection, position,...)
context text, -- pdl_context (eg. official, test,...)
status text, -- importing/done/deprecated
comment_list list<text>, -- comments (eg. why import failed, ...)
version text,
filename text, -- PDL file location
request_list list<text>, -- request_list (eg. flows, fixings,
contract_information,...)
label_list set<text>, -- list of all labels stored in
pdl_caching for this PDL identity
-- (it could be useful for data
purging)
PRIMARY KEY (id, date)
);
CREATE INDEX ON pdl_identity(portfolio);
{code}
> Performing a "Select count(*)" when replication factor < node count causes
> assertion error and timeout
> ------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-6004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6004
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Environment: Two node setup
> Ubuntu Server 12.04
> Tested on JDK 1.6 and 1.7
> Reporter: James P
> Assignee: Sylvain Lebresne
> Fix For: 2.0.1
>
> Attachments: 6004.txt
>
>
> When performing a "Select Count()" query on a table belonging to a keyspace
> with a replication factor less than the total node count, the following error
> is encountered which ultimately results in an rpc_timeout for the request:
> ERROR 18:47:54,660 Exception in thread Thread[Thread-5,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.db.filter.IDiskAtomFilter$Serializer.deserialize(IDiskAtomFilter.java:116)
> at
> org.apache.cassandra.db.RangeSliceCommandSerializer.deserialize(RangeSliceCommand.java:247)
> at
> org.apache.cassandra.db.RangeSliceCommandSerializer.deserialize(RangeSliceCommand.java:156)
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:148)
> at
> org.apache.cassandra.net.IncomingTcpConnection.handleModernVersion(IncomingTcpConnection.java:125)
> at
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:73)
> The issue is not encountered when the replication factor is >= node count
> To replicate the issue:
> 1) Create the keyspace: CREATE KEYSPACE demodb WITH REPLICATION = {'class' :
> 'SimpleStrategy', 'replication_factor': 1};
> 2) Create the table CREATE TABLE users (
> user_name varchar,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint,
> PRIMARY KEY (user_name));
> 3) Do a CQL query: "SELECT count( * ) FROM demodb.users" ;
> The issue is reproducible even if the table is empty. Both CQLSH and client
> (astyanax) api calls are affected. Tested on two different clusters (2-node
> and 8-node)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
