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 >> >> >