So, far I do not have any sucess in trying to reproduce the problem.
I created a 3 node clusters using 3.9 with ccm and used CQLSH to reproduce
the problem but I only got back one row:
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 3};
cqlsh> use test;
cqlsh:test> create table demo (id text, id2 bigint static, added timestamp,
source
... text static, dest text, primary key (id, added));
cqlsh:test> create index on demo (id2);
cqlsh:test> insert into demo (id, id2, added, source, dest) values ('id1',
22,
... '2017-01-28', 'src1', 'dst1');
cqlsh:test> select * from demo where id2=22;
id | added | id2 | source | dest
-----+---------------------------------+-----+--------+------
id1 | 2017-01-27 23:00:00.000000+0000 | 22 | src1 | dst1
(1 rows)
cqlsh:test>
Did you use CQLSH to reproduce the problem or another client?
On Mon, Jan 30, 2017 at 2:39 PM, Benjamin Lerer <benjamin.le...@datastax.com
> wrote:
> I will try to reproduce the problem.
> Thanks for the information
>
> On Mon, Jan 30, 2017 at 2:34 PM, Micha <mich...@fantasymail.de> wrote:
>
>> I have restarted the three node cluster with new directories for data
>> and commitlog and made the test again.
>>
>> This time the resultset size is 62 rows for the select.
>> If I execute the select often it jumps between 62 and 65 rows.
>>
>> After inserting a second row I get 129 rows back I select using the id2
>> of the new row.
>>
>>
>> I have no idea what the cause is, espacially if it works for you.
>>
>> One thing: cassandra startup log says I should use the newest oracle
>> release instead of openjdk. Is this possibly causing trouble?
>>
>>
>> cheers,
>> Michael
>>
>>
>
