[jira] [Commented] (CASSANDRA-10441) Move stress tool into it's own repository and manage dependency on Cassandra externally
[ https://issues.apache.org/jira/browse/CASSANDRA-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942195#comment-14942195 ] Nitsan Wakart commented on CASSANDRA-10441: --- I'm primarily interested in 1 as it would allow me to make contribution similar to those made to YCSB in enhancing the measurement collection and analysis infrastructure. > Move stress tool into it's own repository and manage dependency on Cassandra > externally > --- > > Key: CASSANDRA-10441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10441 > Project: Cassandra > Issue Type: Wish > Components: Tools >Reporter: Nitsan Wakart >Priority: Minor > > This will: > 1. Allow distinct release/maintenance/contribution cycles > 2. Prevent accidental dependencies from Cassandra into the stress tool > 3. Isolate performance changes in Cassandra from changes to stress tool > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10441) Move stress tool into it's own repository and manage dependency on Cassandra externally
Nitsan Wakart created CASSANDRA-10441: - Summary: Move stress tool into it's own repository and manage dependency on Cassandra externally Key: CASSANDRA-10441 URL: https://issues.apache.org/jira/browse/CASSANDRA-10441 Project: Cassandra Issue Type: Wish Components: Tools Reporter: Nitsan Wakart Priority: Minor This will: 1. Allow distinct release/maintenance/contribution cycles 2. Prevent accidental dependencies from Cassandra into the stress tool 3. Isolate performance changes in Cassandra from changes to stress tool -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942242#comment-14942242 ] Gary Stewart commented on CASSANDRA-9602: - In (certain) versions 2.0 this was supported: http://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html In version 2.1 it is now suddenly not supported. http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_config_consistency_c.html This is actually a breaking change in the upgrade path and will hurt clients especially when using it for multi-tenancy solutions. Our use-case is is very heavy writes where latency matters thus we choose CL=LOCAL_QUORUM and seriously few reads where latency does not matter thus we choose to use CL=EACH_QUORUM. This is the minimum to ensure strong consistency which we also need. Now, we are now forced to change to ALL with downgrading consistency. > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942244#comment-14942244 ] Gary Stewart commented on CASSANDRA-9602: - Related to https://issues.apache.org/jira/browse/CASSANDRA-6970 > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6970) Support CL=EACH_QUORUM for reads
[ https://issues.apache.org/jira/browse/CASSANDRA-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942245#comment-14942245 ] Gary Stewart commented on CASSANDRA-6970: - related to https://issues.apache.org/jira/browse/CASSANDRA-9602 > Support CL=EACH_QUORUM for reads > > > Key: CASSANDRA-6970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6970 > Project: Cassandra > Issue Type: Wish > Environment: SLES 11 SP3 x86_64 > Cassandra 2.0.6 >Reporter: Oliver Seiler > > SELECTs done at CL=EACH_QUORUM get an InvalidRequestException: with a message > of "EACH_QUORUM ConsistencyLevel is only supported for writes". > The documentation doesn't indicate this would happen, so at minimum this is > inconsistent with the current documentation. I'm aware of CASSANDRA-3272, > which indicates this has never worked as expected, and made this obvious with > the InvalidRequestException. > I'm not sure why this shouldn't work, regardless of Jonathan Ellis commenting > "I ask because I've never seen it to be the 'right' CL yet". I'd like it > because: I want to do my writes at LOCAL_QUORUM and (some) reads at > EACH_QUORUM, because I require guaranteed consistency for (some) reads where > I can be partition intolerant without affecting clients, rather than becoming > partition intolerant on writes... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10381) NullPointerException in cqlsh paging through CF with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942430#comment-14942430
]
Benjamin Lerer commented on CASSANDRA-10381:
The problem was coming from the fact that the code was not handling properly
the case where the paging was occuring on a partition containing some values
only for the static columns.
The patch for {{2.1}} and {{2.2}} is
[here|https://github.com/apache/cassandra/compare/trunk...blerer:10381-2.1].
The patch for {{3.0}} is
[here|https://github.com/apache/cassandra/compare/trunk...blerer:10381-3.0].
* the unit test results for 2.1 are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-2.1-testall/1/]
* the dtest results for 2.1 are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-2.1-dtest/1/]
* the unit test results for 2.2 are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-2.2-testall/1/]
* the dtest results for 2.2 are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-2.2-dtest/1/]
* the unit test results for 3.0 are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-3.0-testall/2/]
* the dtest results for 3.0 are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-3.0-dtest/2/]
[~slebresne], master of paging, could you review?
I have some doubts for my approach for 3.0.
[~Michael Keeney] I was not able to get a {{NPE}} at exactly the same line as
the one of the description. I could only manage to get it on the next line. I
believe that problem is the one that I have found but it might be could to
check if the dataset that has caused the {{NPE}} has some partitions that
contains some values only for the static columns.
> NullPointerException in cqlsh paging through CF with static columns
> ---
>
> Key: CASSANDRA-10381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10381
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Michael Keeney
>Assignee: Benjamin Lerer
> Labels: cqlsh, nullpointerexception, range
> Fix For: 2.1.x
>
>
> When running select count( * ) from cqlsh with limit, the following NPE
> occurs:
> select count( * ) from tbl1 limit 5 ;
> {code}
> ERROR [SharedPool-Worker-4] 2015-09-16 14:49:43,480 QueryMessage.java:132 -
> Unexpected error during query
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.containsPreviousLast(RangeSliceQueryPager.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.pageCountQuery(SelectStatement.java:286)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:230)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$StatementExecution.execute(DseQueryHandler.java:291)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithTiming(DseQueryHandler.java:223)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithAuditLogging(DseQueryHandler.java:259)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler.process(DseQueryHandler.java:94)
> ~[dse-4.7.2.jar:4.7.2]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
>
[jira] [Commented] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942440#comment-14942440
]
Benjamin Lerer commented on CASSANDRA-10271:
Thanks for the new patch.
Your patch does not seem to handle cases like:
* {{SELECT * FROM %s WHERE a=? AND b=? AND c >= ? ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a=? AND b=? AND c IN (?, ?) ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a=? AND b=? AND (c , d) > (?, ?) ORDER BY c ASC, d
ASC}}
You should also add some unit tests for post-ordering. For queries like:
* {{SELECT * FROM %s WHERE a IN (?, ?) AND b=? ORDER BY c ASC}}
* {{SELECT * FROM %s WHERE a IN (?, ?) AND b=? AND c >= ? ORDER BY c ASC}}
{quote}
Wasn't really sure the best way to approach restricting to an IN restriction
with only one value.
{quote}
{{SingleColumnRestriction}} and {{MultiColumnRestriction}} support 2 types of
{{IN}} restrictions: with values (e.g. {{b IN (?, ?, ?)}}) and with marker
(e.g. {{IN ?}}). In the case of {{IN}} with values you can check the number of
terms.
> ORDER BY should allow skipping equality-restricted clustering columns
> -
>
> Key: CASSANDRA-10271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10271
> Project: Cassandra
> Issue Type: Bug
> Components: API, Core
>Reporter: Tyler Hobbs
>Assignee: Brett Snyder
>Priority: Minor
> Fix For: 3.x, 2.2.x
>
> Attachments: cassandra-2.2-10271.txt
>
>
> Given a table like the following:
> {noformat}
> CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c));
> {noformat}
> We should support a query like this:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC;
> {noformat}
> Currently, this results in the following error:
> {noformat}
> [Invalid query] message="Order by currently only support the ordering of
> columns following their declared order in the PRIMARY KEY"
> {noformat}
> However, since {{b}} is restricted by an equality restriction, we shouldn't
> require it to be present in the {{ORDER BY}} clause.
> As a workaround, you can use this query instead:
> {noformat}
> SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10442) Paging returns duplicate records
Robert Wille created CASSANDRA-10442:
Summary: Paging returns duplicate records
Key: CASSANDRA-10442
URL: https://issues.apache.org/jira/browse/CASSANDRA-10442
Project: Cassandra
Issue Type: Bug
Reporter: Robert Wille
When I execute "SELECT image FROM roll WHERE roll = ?" against
CREATE TABLE roll (
roll INT,
image BIGINT,
data VARCHAR static,
PRIMARY KEY ((roll), image)
) WITH gc_grace_seconds = 3456000 AND compaction = { 'class' :
'LeveledCompactionStrategy', 'sstable_size_in_mb' : 160 };
The image returned from the query is duplicated every fetchSize records (i.e.
1, 2, 3, 3, 4, 5, 6, 6, etc). I can reproduce this easily 100% of the time in
Cassandra 2.0.16 with Java Driver 2.0.11 and RF=3 and CL=QUORUM or ONE. If you
need sample code, I can provide, but given the simplicity, I suspect it will be
easy to reproduce.
I realize this bug might be in the Java driver, but I don't know, so I'm
logging it here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10443) CQLSStableWriter example fails on 3.0rc1
[ https://issues.apache.org/jira/browse/CASSANDRA-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Shook updated CASSANDRA-10443: --- Summary: CQLSStableWriter example fails on 3.0rc1 (was: CQLSStableWriter example fails on C*3.0) > CQLSStableWriter example fails on 3.0rc1 > > > Key: CASSANDRA-10443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10443 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Jonathan Shook > > CQLSSTableWriter which works with 2.2.1 does not work with 3.0rc1. > Something like https://github.com/yukim/cassandra-bulkload-example should be > added to the test suite. > Exception in thread "main" java.lang.RuntimeException: > java.lang.ExceptionInInitializerError > at > org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter.close(SSTableSimpleUnsortedWriter.java:136) > at > org.apache.cassandra.io.sstable.CQLSSTableWriter.close(CQLSSTableWriter.java:274) > at com.metawiring.sandbox.BulkLoadExample.main(BulkLoadExample.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) > Caused by: java.lang.ExceptionInInitializerError > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:372) > at org.apache.cassandra.db.Keyspace.(Keyspace.java:309) > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:133) > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:110) > at > org.apache.cassandra.io.sstable.SSTableTxnWriter.create(SSTableTxnWriter.java:97) > at > org.apache.cassandra.io.sstable.AbstractSSTableSimpleWriter.createWriter(AbstractSSTableSimpleWriter.java:63) > at > org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:206) > Caused by: java.lang.NullPointerException > at > org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1153) > at > org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:116) > ... 7 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10442) Paging repeats records
[
https://issues.apache.org/jira/browse/CASSANDRA-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942561#comment-14942561
]
Robert Wille commented on CASSANDRA-10442:
--
Don't know if anyone has looked at this yet, but I completely rewrote the
ticket, and included sample code instead of just describing it. I also cleared
up some of the description.
> Paging repeats records
> --
>
> Key: CASSANDRA-10442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10442
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Wille
>
> Paging repeats records every fetchSize records. The following sample easily
> reproduces the problem on Cassandra 2.0.16 with Java Driver 2.0.11.
> public class TestPagingBug
> {
> public static void main(String[] args)
> {
> Cluster.Builder builder = Cluster.builder();
>
> Cluster c = builder.addContactPoints("192.168.98.190").build();
>
> Session s = c.connect();
>
> s.execute("CREATE KEYSPACE IF NOT EXISTS test WITH replication
> = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }");
> s.execute("CREATE TABLE IF NOT EXISTS test.test_page(id INT,
> sec BIGINT, data VARCHAR static, PRIMARY KEY ((id), sec))");
> s.execute("INSERT INTO test.test_page (id, data) VALUES (1,
> 'asdfasdfasdfasdfasdfasdf')");
>
> PreparedStatement insert = s.prepare("INSERT INTO
> test.test_page (id, sec) VALUES (1, ?)");
>
> for (int i = 0; i < 1000; i++)
> {
> s.execute(insert.bind((long) i));
> }
>
> PreparedStatement select = s.prepare("SELECT sec FROM
> test.test_page WHERE id = 1");
>
> long lastSec = -1;
>
> for (Row row : s.execute(select.bind().setFetchSize(300)))
> {
> long sec = row.getLong("sec");
>
> if (sec == lastSec)
> {
> System.out.println(String.format("Duplicated id
> %d", sec));
> }
>
> lastSec = sec;
> }
>
> System.exit(0);
> }
> }
> The program outputs the following:
> Duplicated id 299
> Duplicated id 598
> Duplicated id 897
> Note that the static column is required. This bug doesn't occur if you remove
> the column from the schema.
> I realize that this may be a driver bug, but I don't really know, so I'm
> logging it here until that can be determined.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10442) Paging repeats records
[
https://issues.apache.org/jira/browse/CASSANDRA-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Wille updated CASSANDRA-10442:
-
Description:
Paging repeats records every fetchSize records. The following sample easily
reproduces the problem on Cassandra 2.0.16 with Java Driver 2.0.11.
public class TestPagingBug
{
public static void main(String[] args)
{
Cluster.Builder builder = Cluster.builder();
Cluster c = builder.addContactPoints("192.168.98.190").build();
Session s = c.connect();
s.execute("CREATE KEYSPACE IF NOT EXISTS test WITH replication
= { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }");
s.execute("CREATE TABLE IF NOT EXISTS test.test_page(id INT,
sec BIGINT, data VARCHAR static, PRIMARY KEY ((id), sec))");
s.execute("INSERT INTO test.test_page (id, data) VALUES (1,
'asdfasdfasdfasdfasdfasdf')");
PreparedStatement insert = s.prepare("INSERT INTO
test.test_page (id, sec) VALUES (1, ?)");
for (int i = 0; i < 1000; i++)
{
s.execute(insert.bind((long) i));
}
PreparedStatement select = s.prepare("SELECT sec FROM
test.test_page WHERE id = 1");
long lastSec = -1;
for (Row row : s.execute(select.bind().setFetchSize(300)))
{
long sec = row.getLong("sec");
if (sec == lastSec)
{
System.out.println(String.format("Duplicated id
%d", sec));
}
lastSec = sec;
}
System.exit(0);
}
}
The program outputs the following:
Duplicated id 299
Duplicated id 598
Duplicated id 897
Note that the static column is required. This bug doesn't occur if you remove
the column from the schema.
I realize that this may be a driver bug, but I don't really know, so I'm
logging it here until that can be determined.
was:Paging returns repeats
Summary: Paging repeats records (was: Paging returns duplicate records)
> Paging repeats records
> --
>
> Key: CASSANDRA-10442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10442
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Wille
>
> Paging repeats records every fetchSize records. The following sample easily
> reproduces the problem on Cassandra 2.0.16 with Java Driver 2.0.11.
> public class TestPagingBug
> {
> public static void main(String[] args)
> {
> Cluster.Builder builder = Cluster.builder();
>
> Cluster c = builder.addContactPoints("192.168.98.190").build();
>
> Session s = c.connect();
>
> s.execute("CREATE KEYSPACE IF NOT EXISTS test WITH replication
> = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }");
> s.execute("CREATE TABLE IF NOT EXISTS test.test_page(id INT,
> sec BIGINT, data VARCHAR static, PRIMARY KEY ((id), sec))");
> s.execute("INSERT INTO test.test_page (id, data) VALUES (1,
> 'asdfasdfasdfasdfasdfasdf')");
>
> PreparedStatement insert = s.prepare("INSERT INTO
> test.test_page (id, sec) VALUES (1, ?)");
>
> for (int i = 0; i < 1000; i++)
> {
> s.execute(insert.bind((long) i));
> }
>
> PreparedStatement select = s.prepare("SELECT sec FROM
> test.test_page WHERE id = 1");
>
> long lastSec = -1;
>
> for (Row row : s.execute(select.bind().setFetchSize(300)))
> {
> long sec = row.getLong("sec");
>
> if (sec == lastSec)
> {
> System.out.println(String.format("Duplicated id
> %d", sec));
> }
>
> lastSec = sec;
> }
>
> System.exit(0);
> }
> }
> The program outputs the following:
> Duplicated id 299
> Duplicated id 598
> Duplicated id 897
> Note that the static column is required. This bug doesn't occur if you remove
> the column from the schema.
> I realize that this may be a driver bug, but I don't really know, so I'm
> logging it here until that can be determined.
--
This message was sent by Atlassian JIRA
[jira] [Updated] (CASSANDRA-10442) Paging returns duplicate records
[
https://issues.apache.org/jira/browse/CASSANDRA-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Wille updated CASSANDRA-10442:
-
Description: Paging returns repeats (was: When I execute "SELECT image
FROM roll WHERE roll = ?" against
CREATE TABLE roll (
roll INT,
image BIGINT,
data VARCHAR static,
PRIMARY KEY ((roll), image)
) WITH gc_grace_seconds = 3456000 AND compaction = { 'class' :
'LeveledCompactionStrategy', 'sstable_size_in_mb' : 160 };
The image returned from the query is duplicated every fetchSize records (i.e.
1, 2, 3, 3, 4, 5, 6, 6, etc). I can reproduce this easily 100% of the time in
Cassandra 2.0.16 with Java Driver 2.0.11 and RF=3 and CL=QUORUM or ONE. If you
need sample code, I can provide, but given the simplicity, I suspect it will be
easy to reproduce.
I realize this bug might be in the Java driver, but I don't know, so I'm
logging it here.)
> Paging returns duplicate records
>
>
> Key: CASSANDRA-10442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10442
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Wille
>
> Paging returns repeats
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10443) CQLSStableWriter example fails on C*3.0
Jonathan Shook created CASSANDRA-10443: -- Summary: CQLSStableWriter example fails on C*3.0 Key: CASSANDRA-10443 URL: https://issues.apache.org/jira/browse/CASSANDRA-10443 Project: Cassandra Issue Type: Bug Components: Core, Tools Reporter: Jonathan Shook CQLSSTableWriter which works with 2.2.1 does not work with 3.0rc1. Something like https://github.com/yukim/cassandra-bulkload-example should be added to the test suite. Exception in thread "main" java.lang.RuntimeException: java.lang.ExceptionInInitializerError at org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter.close(SSTableSimpleUnsortedWriter.java:136) at org.apache.cassandra.io.sstable.CQLSSTableWriter.close(CQLSSTableWriter.java:274) at com.metawiring.sandbox.BulkLoadExample.main(BulkLoadExample.java:160) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) Caused by: java.lang.ExceptionInInitializerError at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:372) at org.apache.cassandra.db.Keyspace.(Keyspace.java:309) at org.apache.cassandra.db.Keyspace.open(Keyspace.java:133) at org.apache.cassandra.db.Keyspace.open(Keyspace.java:110) at org.apache.cassandra.io.sstable.SSTableTxnWriter.create(SSTableTxnWriter.java:97) at org.apache.cassandra.io.sstable.AbstractSSTableSimpleWriter.createWriter(AbstractSSTableSimpleWriter.java:63) at org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:206) Caused by: java.lang.NullPointerException at org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1153) at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:116) ... 7 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
