[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605351#comment-14605351 ] Benedict commented on CASSANDRA-9318: - Of course, things get even hairier with multi-DC, but I'm not as familiar with the logic there. It looks naively that a single node could quickly bring down every DC. Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9672) Provide a per-table param that would force default ttl on all updates
[
https://issues.apache.org/jira/browse/CASSANDRA-9672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605477#comment-14605477
]
Sylvain Lebresne commented on CASSANDRA-9672:
-
I'm bikesheding, but one slightly different alternative could be to add a
{{minimum_data_retention_time}} that would be a guarantee on the minimum time
data is guarantee to live in the database. An advantage being that it would
still allow different ttls (and in particular mixing data with ttl and data
without it) but with the guarantee that you can't fat-finger a ttl too low, or
delete data by mistake, which feels to me closer to what a DBA would intend.
It also have a hunch that it's easier to explain why that kind of option forces
us to refuse deletes, but well, that's just a hunch. It should also be fairly
intuitive to reserve a special value (say negative ones) for that option to
mean keep all data forever.
Of course, such option would still allows us to drop sstables cheaply
(technically as long as the min retention is lower than gcGrace, but you can
lower gcGrace if needs be).
Provide a per-table param that would force default ttl on all updates
-
Key: CASSANDRA-9672
URL: https://issues.apache.org/jira/browse/CASSANDRA-9672
Project: Cassandra
Issue Type: Improvement
Reporter: Aleksey Yeschenko
Priority: Minor
Many users have tables that rely on TTL entirely - no deletes, and only fixed
TTL value.
The way that default ttl works now, we only apply it if none is specified.
We should provide an option that would *enforce* the specified TTL. Not
allowing ttl-less {{INSERT}} or {{UPDATE}}, not allowing ttl that's lower or
higher than the default ttl, and not allowing deletes.
That option when enabled ({{force_default_ttl}}) should allow us to drop more
tables during compaction and do so cheaper. Would also allow the DBAs to
enforce the constraint in a guaranteed manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605600#comment-14605600 ] Benedict commented on CASSANDRA-9318: - That said, in general (perhaps in a separate ticket) we should probably make our heap calculations a bit more robust wrt each other. i.e. we should subtract memtable space from any heap apportionment, in case users set memtable space really high. Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9675) BulkLoader has --transport-factory option but does not use it
Mike Adamson created CASSANDRA-9675: --- Summary: BulkLoader has --transport-factory option but does not use it Key: CASSANDRA-9675 URL: https://issues.apache.org/jira/browse/CASSANDRA-9675 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Mike Adamson Assignee: Mike Adamson Fix For: 2.2.x The BulkLoader tool was converted to use the native driver but still has a --transport-factory option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9675) BulkLoader has --transport-factory option but does not use it
[ https://issues.apache.org/jira/browse/CASSANDRA-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-9675: Priority: Minor (was: Major) BulkLoader has --transport-factory option but does not use it - Key: CASSANDRA-9675 URL: https://issues.apache.org/jira/browse/CASSANDRA-9675 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Mike Adamson Assignee: Mike Adamson Priority: Minor Fix For: 2.2.x Attachments: 9675.txt The BulkLoader tool was converted to use the native driver but still has a --transport-factory option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9675) BulkLoader has --transport-factory option but does not use it
[ https://issues.apache.org/jira/browse/CASSANDRA-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-9675: Attachment: 9675.txt BulkLoader has --transport-factory option but does not use it - Key: CASSANDRA-9675 URL: https://issues.apache.org/jira/browse/CASSANDRA-9675 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Mike Adamson Assignee: Mike Adamson Fix For: 2.2.x Attachments: 9675.txt The BulkLoader tool was converted to use the native driver but still has a --transport-factory option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/2] cassandra git commit: BulkLoader has --transport-factory option but does not use it
Repository: cassandra Updated Branches: refs/heads/trunk e211008d5 - 5c31a8633 BulkLoader has --transport-factory option but does not use it patch by Mike Adamson; reviewed by jasobrown for CASSANDRA-9675 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f88b6211 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f88b6211 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f88b6211 Branch: refs/heads/trunk Commit: f88b62118dd9d3f08bc079bc15165fae01519537 Parents: bafcb3a Author: Jason Brown jasedbr...@gmail.com Authored: Mon Jun 29 07:10:53 2015 -0700 Committer: Jason Brown jasedbr...@gmail.com Committed: Mon Jun 29 07:10:53 2015 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/tools/BulkLoader.java | 4 2 files changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f88b6211/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e58d524..fe71ea7 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2 + * BulkLoader has --transport-factory option but does not use it (CASSANDRA-9675) * Allow JMX over SSL directly from nodetool (CASSANDRA-9090) * Update cqlsh for UDFs (CASSANDRA-7556) * Change Windows kernel default timer resolution (CASSANDRA-9634) http://git-wip-us.apache.org/repos/asf/cassandra/blob/f88b6211/src/java/org/apache/cassandra/tools/BulkLoader.java -- diff --git a/src/java/org/apache/cassandra/tools/BulkLoader.java b/src/java/org/apache/cassandra/tools/BulkLoader.java index 51e5e3d..73194a1 100644 --- a/src/java/org/apache/cassandra/tools/BulkLoader.java +++ b/src/java/org/apache/cassandra/tools/BulkLoader.java @@ -24,7 +24,6 @@ import java.net.MalformedURLException; import java.net.UnknownHostException; import java.util.*; -import com.google.common.base.Optional; import com.google.common.collect.HashMultimap; import com.google.common.collect.Multimap; import org.apache.commons.cli.*; @@ -53,8 +52,6 @@ public class BulkLoader private static final String PASSWD_OPTION = password; private static final String THROTTLE_MBITS = throttle; -private static final String TRANSPORT_FACTORY = transport-factory; - /* client encryption options */ private static final String SSL_TRUSTSTORE = truststore; private static final String SSL_TRUSTSTORE_PW = truststore-password; @@ -516,7 +513,6 @@ public class BulkLoader options.addOption(t, THROTTLE_MBITS, throttle, throttle speed in Mbits (default unlimited)); options.addOption(u, USER_OPTION, username, username for cassandra authentication); options.addOption(pw, PASSWD_OPTION, password, password for cassandra authentication); -options.addOption(tf, TRANSPORT_FACTORY, transport factory, Fully-qualified ITransportFactory class name for creating a connection to cassandra); options.addOption(cph, CONNECTIONS_PER_HOST, connectionsPerHost, number of concurrent connections-per-host.); // ssl connection-related options options.addOption(ts, SSL_TRUSTSTORE, TRUSTSTORE, Client SSL: full path to truststore);
[jira] [Resolved] (CASSANDRA-8298) cassandra-stress legacy
[ https://issues.apache.org/jira/browse/CASSANDRA-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani resolved CASSANDRA-8298. --- Resolution: Duplicate This should happen as part of CASSANDRA-8986 cassandra-stress legacy Key: CASSANDRA-8298 URL: https://issues.apache.org/jira/browse/CASSANDRA-8298 Project: Cassandra Issue Type: Bug Components: Tools Environment: Centos 6.5 Cassandra 2.1.1 Reporter: Edgardo Vega Assignee: T Jake Luciani Running cassandra-stress legacy failed immediately with a error. Running in legacy support mode. Translating command to: stress write n=100 -col n=fixed(5) size=fixed(34) data=repeat(1) -rate threads=50 -log interval=10 -mode thrift Invalid parameter data=repeat(1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8597) Stress: make simple things simple
[ https://issues.apache.org/jira/browse/CASSANDRA-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani resolved CASSANDRA-8597. --- Resolution: Duplicate Closing in favor of CASSANDRA-8986 Stress: make simple things simple - Key: CASSANDRA-8597 URL: https://issues.apache.org/jira/browse/CASSANDRA-8597 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jonathan Ellis Assignee: T Jake Luciani Fix For: 2.1.x Some of the trouble people have with stress is a documentation problem, but some is functional. Comments from [~iamaleksey]: # 3 clustering columns, make a million cells in a single partition, should be simple, but it's not. have to tweak 'clustering' on the three columns just right to make stress work at all. w/ some values it'd just gets stuck forever computing batches # for others, it generates huge, megabyte-size batches, utterly disrespecting 'select' clause in 'insert' # I want a sequential generator too, to be able to predict deterministic result sets. uniform() only gets you so far # impossible to simulate a time series workload /cc [~jshook] [~aweisberg] [~benedict] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8696) nodetool repair on cassandra 2.1.2 keyspaces return java.lang.RuntimeException: Could not create snapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605603#comment-14605603
]
A Markov commented on CASSANDRA-8696:
-
Yuki, I am not sure that increasing timeout to 1 hour is a good solution. We
are using 2.1.7 system and getting into situation that repair totally stops for
an hour. I might be wrong but it looks like repair doesn't start another
session until all tasks of a current session are finished one way or another.
So if one of the tasks of the current session fails without immediate message,
in our example it is exactly same error about failed snapshot
RepairJob.java:145 - Error occurred during snapshot phase
repair just idles for an hour resuming it's work after processing that
exception. As a result of that system could not finish repair in realistic time
(still working after 7 days).
nodetool repair on cassandra 2.1.2 keyspaces return
java.lang.RuntimeException: Could not create snapshot
-
Key: CASSANDRA-8696
URL: https://issues.apache.org/jira/browse/CASSANDRA-8696
Project: Cassandra
Issue Type: Bug
Reporter: Jeff Liu
Assignee: Yuki Morishita
Fix For: 2.1.x
When trying to run nodetool repair -pr on cassandra node ( 2.1.2), cassandra
throw java exceptions: cannot create snapshot.
the error log from system.log:
{noformat}
INFO [STREAM-IN-/10.97.9.110] 2015-01-28 02:07:28,815
StreamResultFuture.java:166 - [Stream #692c1450-a692-11e4-9973-070e938df227
ID#0] Prepare completed. Receiving 2 files(221187 bytes), sending 5
files(632105 bytes)
INFO [STREAM-IN-/10.97.9.110] 2015-01-28 02:07:29,046
StreamResultFuture.java:180 - [Stream #692c1450-a692-11e4-9973-070e938df227]
Session with /10.97.9.110 is complete
INFO [STREAM-IN-/10.97.9.110] 2015-01-28 02:07:29,046
StreamResultFuture.java:212 - [Stream #692c1450-a692-11e4-9973-070e938df227]
All sessions completed
INFO [STREAM-IN-/10.97.9.110] 2015-01-28 02:07:29,047
StreamingRepairTask.java:96 - [repair #685e3d00-a692-11e4-9973-070e938df227]
streaming task succeed, returning response to /10.98.194.68
INFO [RepairJobTask:1] 2015-01-28 02:07:29,065 StreamResultFuture.java:86 -
[Stream #692c6270-a692-11e4-9973-070e938df227] Executing streaming plan for
Repair
INFO [StreamConnectionEstablisher:4] 2015-01-28 02:07:29,065
StreamSession.java:213 - [Stream #692c6270-a692-11e4-9973-070e938df227]
Starting streaming to /10.66.187.201
INFO [StreamConnectionEstablisher:4] 2015-01-28 02:07:29,070
StreamCoordinator.java:209 - [Stream #692c6270-a692-11e4-9973-070e938df227,
ID#0] Beginning stream session with /10.66.187.201
INFO [STREAM-IN-/10.66.187.201] 2015-01-28 02:07:29,465
StreamResultFuture.java:166 - [Stream #692c6270-a692-11e4-9973-070e938df227
ID#0] Prepare completed. Receiving 5 files(627994 bytes), sending 5
files(632105 bytes)
INFO [StreamReceiveTask:22] 2015-01-28 02:07:31,971
StreamResultFuture.java:180 - [Stream #692c6270-a692-11e4-9973-070e938df227]
Session with /10.66.187.201 is complete
INFO [StreamReceiveTask:22] 2015-01-28 02:07:31,972
StreamResultFuture.java:212 - [Stream #692c6270-a692-11e4-9973-070e938df227]
All sessions completed
INFO [StreamReceiveTask:22] 2015-01-28 02:07:31,972
StreamingRepairTask.java:96 - [repair #685e3d00-a692-11e4-9973-070e938df227]
streaming task succeed, returning response to /10.98.194.68
ERROR [RepairJobTask:1] 2015-01-28 02:07:39,444 RepairJob.java:127 - Error
occurred during snapshot phase
java.lang.RuntimeException: Could not create snapshot at /10.97.9.110
at
org.apache.cassandra.repair.SnapshotTask$SnapshotCallback.onFailure(SnapshotTask.java:77)
~[apache-cassandra-2.1.2.jar:2.1.2]
at
org.apache.cassandra.net.MessagingService$5$1.run(MessagingService.java:347)
~[apache-cassandra-2.1.2.jar:2.1.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_45]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
INFO [AntiEntropySessions:6] 2015-01-28 02:07:39,445 RepairSession.java:260
- [repair #6f85e740-a692-11e4-9973-070e938df227] new session: will sync
/10.98.194.68, /10.66.187.201, /10.226.218.135 on range
(12817179804668051873746972069086
2638799,12863540308359254031520865977436165] for events.[bigint0text,
bigint0boolean, bigint0int, dataset_catalog, column_categories,
bigint0double,
[jira] [Assigned] (CASSANDRA-9601) Allow an initial connection timeout to be set in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-9601: - Assignee: Benjamin Lerer (was: Stefania) Allow an initial connection timeout to be set in cqlsh -- Key: CASSANDRA-9601 URL: https://issues.apache.org/jira/browse/CASSANDRA-9601 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Mike Adamson Assignee: Benjamin Lerer Labels: cqlsh Fix For: 2.2.x [PYTHON-206|https://datastax-oss.atlassian.net/browse/PYTHON-206] introduced the ability to change the initial connection timeout on connections from the default of 5s. This change was introduced because some auth providers (kerberos) can take longer than 5s to complete a first time negotiation for a connection. cqlsh should allow this setting to be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] cassandra git commit: Merge branch 'cassandra-2.2' into trunk
Merge branch 'cassandra-2.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5c31a863 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5c31a863 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5c31a863 Branch: refs/heads/trunk Commit: 5c31a8633485493fec392ebcb9d950b57745e456 Parents: e211008 f88b621 Author: Jason Brown jasedbr...@gmail.com Authored: Mon Jun 29 07:12:13 2015 -0700 Committer: Jason Brown jasedbr...@gmail.com Committed: Mon Jun 29 07:12:13 2015 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/tools/BulkLoader.java | 4 2 files changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/5c31a863/CHANGES.txt -- diff --cc CHANGES.txt index ff80121,fe71ea7..206b15d --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,17 -1,5 +1,18 @@@ +3.0: + * Improve log output from unit tests (CASSANDRA-9528) + * Add algorithmic token allocation (CASSANDRA-7032) + * Add nodetool command to replay batchlog (CASSANDRA-9547) + * Make file buffer cache independent of paths being read (CASSANDRA-8897) + * Remove deprecated legacy Hadoop code (CASSANDRA-9353) + * Decommissioned nodes will not rejoin the cluster (CASSANDRA-8801) + * Change gossip stabilization to use endpoit size (CASSANDRA-9401) + * Change default garbage collector to G1 (CASSANDRA-7486) + * Populate TokenMetadata early during startup (CASSANDRA-9317) + * undeprecate cache recentHitRate (CASSANDRA-6591) + + 2.2 + * BulkLoader has --transport-factory option but does not use it (CASSANDRA-9675) * Allow JMX over SSL directly from nodetool (CASSANDRA-9090) * Update cqlsh for UDFs (CASSANDRA-7556) * Change Windows kernel default timer resolution (CASSANDRA-9634)
[jira] [Created] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
Vladimir Kuptsov created CASSANDRA-9676:
---
Summary: CQLSSTableWriter gives java.lang.AssertionError: Empty
partition in C* 2.0.15
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which regulated with
the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9636) Duplicate columns in selection causes AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605548#comment-14605548
]
Benjamin Lerer commented on CASSANDRA-9636:
---
I noticed an issue with {{count(*)}} queries.
Up to 2.2, the count function was implemented in a different way than the other
functions. It was some form of hack in {{SelectStatement}}. Due to that the
mapping returned is wrong for this function.
To be on the safe side, I think it will be good to add some tests for duplicate
function calls and for 2.2 some tests with aggregations.
Duplicate columns in selection causes AssertionError
Key: CASSANDRA-9636
URL: https://issues.apache.org/jira/browse/CASSANDRA-9636
Project: Cassandra
Issue Type: Bug
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
Fix For: 2.1.x, 2.0.x
Prior to CASSANDRA-9532, unaliased duplicate fields in a selection would be
silently ignored. Now, they trigger a server side exception and an unfriendly
error response, which we should clean up. Duplicate columns *with* aliases
are not affected.
{code}
CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
CREATE TABLE ks.t1 (k int PRIMARY KEY, v int);
INSERT INTO ks.t2 (k, v) VALUES (0, 0);
SELECT k, v FROM ks.t2;
SELECT k, v, v AS other_v FROM ks.t2;
SELECT k, v, v FROM ks.t2;
{code}
The final statement results in this error response server side stacktrace:
{code}
ServerError: ErrorMessage code= [Server error]
message=java.lang.AssertionError
ERROR 13:01:30 Unexpected exception during request; channel = [id:
0x44d22e61, /127.0.0.1:39463 = /127.0.0.1:9042]
java.lang.AssertionError: null
at org.apache.cassandra.cql3.ResultSet.addRow(ResultSet.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.statements.Selection$ResultSetBuilder.build(Selection.java:355)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1226)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:299)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:238)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:260)
~[main/:na]
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
~[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[main/:na]
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
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_45]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
{code}
This issue also presents on the head of the 2.2 branch and on 2.0.16.
However, the prior behaviour is different on both of those branches.
In the 2.0 line prior to CASSANDRA-9532, duplicate columns would actually be
included in the results, as opposed to being silently dropped as per 2.1.x
In 2.2, the assertion error seen above precedes CASSANDRA-9532 and is also
triggered for both aliased and unaliased duplicate columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9606) this query is not supported in new version
[
https://issues.apache.org/jira/browse/CASSANDRA-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1460#comment-1460
]
Benjamin Lerer edited comment on CASSANDRA-9606 at 6/29/15 12:48 PM:
-
[~thobbs] could you review?
was (Author: blerer):
@Tyler could you review?
this query is not supported in new version
--
Key: CASSANDRA-9606
URL: https://issues.apache.org/jira/browse/CASSANDRA-9606
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cassandra 2.1.6
jdk 1.7.0_55
Reporter: zhaoyan
Assignee: Benjamin Lerer
Attachments: 9606-2.0.txt, 9606-2.1.txt, 9606-2.2.txt
Background:
1、create a table:
{code}
CREATE TABLE test (
a int,
b int,
c int,
d int,
PRIMARY KEY (a, b, c)
);
{code}
2、query by a=1 and b6
{code}
select * from test where a=1 and b6;
a | b | c | d
---+---+---+---
1 | 3 | 1 | 2
1 | 3 | 2 | 2
1 | 3 | 4 | 2
1 | 3 | 5 | 2
1 | 4 | 4 | 2
1 | 5 | 5 | 2
(6 rows)
{code}
3、query by page
first page：
{code}
select * from test where a=1 and b6 limit 2;
a | b | c | d
---+---+---+---
1 | 3 | 1 | 2
1 | 3 | 2 | 2
(2 rows)
{code}
second page：
{code}
select * from test where a=1 and b6 and (b,c) (3,2) limit 2;
a | b | c | d
---+---+---+---
1 | 3 | 4 | 2
1 | 3 | 5 | 2
(2 rows)
{code}
last page：
{code}
select * from test where a=1 and b6 and (b,c) (3,5) limit 2;
a | b | c | d
---+---+---+---
1 | 4 | 4 | 2
1 | 5 | 5 | 2
(2 rows)
{code}
question:
this query by page is ok when cassandra 2.0.8.
but is not supported in the latest version 2.1.6
when execute：
{code}
select * from test where a=1 and b6 and (b,c) (3,2) limit 2;
{code}
get one error message：
InvalidRequest: code=2200 [Invalid query] message=Column b cannot have
both tuple-notation inequalities and single-column inequalities: (b, c) (3,
2)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9606) this query is not supported in new version
[
https://issues.apache.org/jira/browse/CASSANDRA-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1460#comment-1460
]
Benjamin Lerer commented on CASSANDRA-9606:
---
@Tyler could you review?
this query is not supported in new version
--
Key: CASSANDRA-9606
URL: https://issues.apache.org/jira/browse/CASSANDRA-9606
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cassandra 2.1.6
jdk 1.7.0_55
Reporter: zhaoyan
Assignee: Benjamin Lerer
Attachments: 9606-2.0.txt, 9606-2.1.txt, 9606-2.2.txt
Background:
1、create a table:
{code}
CREATE TABLE test (
a int,
b int,
c int,
d int,
PRIMARY KEY (a, b, c)
);
{code}
2、query by a=1 and b6
{code}
select * from test where a=1 and b6;
a | b | c | d
---+---+---+---
1 | 3 | 1 | 2
1 | 3 | 2 | 2
1 | 3 | 4 | 2
1 | 3 | 5 | 2
1 | 4 | 4 | 2
1 | 5 | 5 | 2
(6 rows)
{code}
3、query by page
first page：
{code}
select * from test where a=1 and b6 limit 2;
a | b | c | d
---+---+---+---
1 | 3 | 1 | 2
1 | 3 | 2 | 2
(2 rows)
{code}
second page：
{code}
select * from test where a=1 and b6 and (b,c) (3,2) limit 2;
a | b | c | d
---+---+---+---
1 | 3 | 4 | 2
1 | 3 | 5 | 2
(2 rows)
{code}
last page：
{code}
select * from test where a=1 and b6 and (b,c) (3,5) limit 2;
a | b | c | d
---+---+---+---
1 | 4 | 4 | 2
1 | 5 | 5 | 2
(2 rows)
{code}
question:
this query by page is ok when cassandra 2.0.8.
but is not supported in the latest version 2.1.6
when execute：
{code}
select * from test where a=1 and b6 and (b,c) (3,2) limit 2;
{code}
get one error message：
InvalidRequest: code=2200 [Invalid query] message=Column b cannot have
both tuple-notation inequalities and single-column inequalities: (b, c) (3,
2)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605597#comment-14605597 ] Benedict commented on CASSANDRA-9318: - bq. default timeout is 2s not 10, so actually fine in your example of 300MB vs 150MB/s x 2s Looks like 2.0 this was 10s, and it was hard-coded in yaml, so anyone upgrading from 2.0 or before likely has a 10s timeout. So we should assume this is by far the most common timeout. bq. you don't see a complete halt until capacity's worth of requests timeout all at once, because you don't get an entire capacity load accepted at once. it's more continuous than discrete – you pause until the oldest expire, accept more, pause until the oldest expire, etc. so you make slow progress as load shedding can free up memory. thus, load shedding is complementary to flow control. You see a complete halt as soon as we exhaust space. If we exhaust space in 0.5x timeout, then we will see repeatedly juddering behaviour. bq. but we can easily set a higher limit on MS heap – maybe as high as 1/8 heap as default which gives us a lot of room for 8GB heap If we set this really _aggressively_ high, say min(1/4 heap, 1Gb) until we implement the improved shedding, then I'll quit complaining. Right now we give breathing room up to and beyond collapse. I absolutely agree that breathing room up until just-prior-to-collapse is preferable, but cutting our breathing room by a magnitude is reducing our availability in clusters without their opting into it. 1/4 heap is probably still leaving quite a lot of headroom we would otherwise have safely used in a 2Gb heap (which are quite feasible, and probably preferable, for many users running offheap memtables), but is still very unlikely to cause the server to completely collapse. Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9601) Allow an initial connection timeout to be set in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-9601: -- Assignee: Stefania (was: Benjamin Lerer) Reviewer: Benjamin Lerer Allow an initial connection timeout to be set in cqlsh -- Key: CASSANDRA-9601 URL: https://issues.apache.org/jira/browse/CASSANDRA-9601 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Mike Adamson Assignee: Stefania Labels: cqlsh Fix For: 2.2.x [PYTHON-206|https://datastax-oss.atlassian.net/browse/PYTHON-206] introduced the ability to change the initial connection timeout on connections from the default of 5s. This change was introduced because some auth providers (kerberos) can take longer than 5s to complete a first time negotiation for a connection. cqlsh should allow this setting to be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: fix idea files issue
Repository: cassandra Updated Branches: refs/heads/cassandra-2.2 75e85b961 - bafcb3a56 fix idea files issue Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bafcb3a5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bafcb3a5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bafcb3a5 Branch: refs/heads/cassandra-2.2 Commit: bafcb3a5689702b9441c6be1cf4c14fb6caf44f0 Parents: 75e85b9 Author: T Jake Luciani j...@apache.org Authored: Mon Jun 29 09:52:57 2015 -0400 Committer: T Jake Luciani j...@apache.org Committed: Mon Jun 29 09:52:57 2015 -0400 -- build.xml | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/bafcb3a5/build.xml -- diff --git a/build.xml b/build.xml index 2eb2d89..8ca3122 100644 --- a/build.xml +++ b/build.xml @@ -1693,13 +1693,10 @@ path id=idea-project-libs-path fileset dir=lib include name=**/*.jar / - /fileset +/fileset fileset dir=build/lib/jars include name=**/*.jar / /fileset -fileset dir=tools/lib -include name=**/*.jar / -/fileset /path mkdir dir=.idea/ mkdir dir=.idea/libraries/
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605629#comment-14605629 ] Jonathan Ellis commented on CASSANDRA-9318: --- bq. If we set this really aggressively high, say min(1/4 heap, 1Gb) until we implement the improved shedding, then I'll quit complaining. Sold! Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: BulkLoader has --transport-factory option but does not use it
Repository: cassandra Updated Branches: refs/heads/cassandra-2.2 bafcb3a56 - f88b62118 BulkLoader has --transport-factory option but does not use it patch by Mike Adamson; reviewed by jasobrown for CASSANDRA-9675 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f88b6211 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f88b6211 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f88b6211 Branch: refs/heads/cassandra-2.2 Commit: f88b62118dd9d3f08bc079bc15165fae01519537 Parents: bafcb3a Author: Jason Brown jasedbr...@gmail.com Authored: Mon Jun 29 07:10:53 2015 -0700 Committer: Jason Brown jasedbr...@gmail.com Committed: Mon Jun 29 07:10:53 2015 -0700 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/tools/BulkLoader.java | 4 2 files changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f88b6211/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e58d524..fe71ea7 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2 + * BulkLoader has --transport-factory option but does not use it (CASSANDRA-9675) * Allow JMX over SSL directly from nodetool (CASSANDRA-9090) * Update cqlsh for UDFs (CASSANDRA-7556) * Change Windows kernel default timer resolution (CASSANDRA-9634) http://git-wip-us.apache.org/repos/asf/cassandra/blob/f88b6211/src/java/org/apache/cassandra/tools/BulkLoader.java -- diff --git a/src/java/org/apache/cassandra/tools/BulkLoader.java b/src/java/org/apache/cassandra/tools/BulkLoader.java index 51e5e3d..73194a1 100644 --- a/src/java/org/apache/cassandra/tools/BulkLoader.java +++ b/src/java/org/apache/cassandra/tools/BulkLoader.java @@ -24,7 +24,6 @@ import java.net.MalformedURLException; import java.net.UnknownHostException; import java.util.*; -import com.google.common.base.Optional; import com.google.common.collect.HashMultimap; import com.google.common.collect.Multimap; import org.apache.commons.cli.*; @@ -53,8 +52,6 @@ public class BulkLoader private static final String PASSWD_OPTION = password; private static final String THROTTLE_MBITS = throttle; -private static final String TRANSPORT_FACTORY = transport-factory; - /* client encryption options */ private static final String SSL_TRUSTSTORE = truststore; private static final String SSL_TRUSTSTORE_PW = truststore-password; @@ -516,7 +513,6 @@ public class BulkLoader options.addOption(t, THROTTLE_MBITS, throttle, throttle speed in Mbits (default unlimited)); options.addOption(u, USER_OPTION, username, username for cassandra authentication); options.addOption(pw, PASSWD_OPTION, password, password for cassandra authentication); -options.addOption(tf, TRANSPORT_FACTORY, transport factory, Fully-qualified ITransportFactory class name for creating a connection to cassandra); options.addOption(cph, CONNECTIONS_PER_HOST, connectionsPerHost, number of concurrent connections-per-host.); // ssl connection-related options options.addOption(ts, SSL_TRUSTSTORE, TRUSTSTORE, Client SSL: full path to truststore);
[1/2] cassandra git commit: fix idea files issue
Repository: cassandra Updated Branches: refs/heads/trunk 4129c0b00 - e211008d5 fix idea files issue Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bafcb3a5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bafcb3a5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bafcb3a5 Branch: refs/heads/trunk Commit: bafcb3a5689702b9441c6be1cf4c14fb6caf44f0 Parents: 75e85b9 Author: T Jake Luciani j...@apache.org Authored: Mon Jun 29 09:52:57 2015 -0400 Committer: T Jake Luciani j...@apache.org Committed: Mon Jun 29 09:52:57 2015 -0400 -- build.xml | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/bafcb3a5/build.xml -- diff --git a/build.xml b/build.xml index 2eb2d89..8ca3122 100644 --- a/build.xml +++ b/build.xml @@ -1693,13 +1693,10 @@ path id=idea-project-libs-path fileset dir=lib include name=**/*.jar / - /fileset +/fileset fileset dir=build/lib/jars include name=**/*.jar / /fileset -fileset dir=tools/lib -include name=**/*.jar / -/fileset /path mkdir dir=.idea/ mkdir dir=.idea/libraries/
[2/2] cassandra git commit: Merge branch 'cassandra-2.2' into trunk
Merge branch 'cassandra-2.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e211008d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e211008d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e211008d Branch: refs/heads/trunk Commit: e211008d5a761e773b8740bdbada21bdcad035c1 Parents: 4129c0b bafcb3a Author: T Jake Luciani j...@apache.org Authored: Mon Jun 29 09:53:46 2015 -0400 Committer: T Jake Luciani j...@apache.org Committed: Mon Jun 29 09:53:46 2015 -0400 -- build.xml | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e211008d/build.xml --
[jira] [Commented] (CASSANDRA-9672) Provide a per-table param that would force default ttl on all updates
[
https://issues.apache.org/jira/browse/CASSANDRA-9672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605484#comment-14605484
]
Aleksey Yeschenko commented on CASSANDRA-9672:
--
Yeah, that could work as well.
That said, a forced single TTL strictness guarantees us that there no
overwrites of the same cells with a lower TTL ever happens, and that *should*
allow us to optimize harder.
We probably could/should provide several different options to hint the usage
patterns, with varying degrees of strictness.
Provide a per-table param that would force default ttl on all updates
-
Key: CASSANDRA-9672
URL: https://issues.apache.org/jira/browse/CASSANDRA-9672
Project: Cassandra
Issue Type: Improvement
Reporter: Aleksey Yeschenko
Priority: Minor
Many users have tables that rely on TTL entirely - no deletes, and only fixed
TTL value.
The way that default ttl works now, we only apply it if none is specified.
We should provide an option that would *enforce* the specified TTL. Not
allowing ttl-less {{INSERT}} or {{UPDATE}}, not allowing ttl that's lower or
higher than the default ttl, and not allowing deletes.
That option when enabled ({{force_default_ttl}}) should allow us to drop more
tables during compaction and do so cheaper. Would also allow the DBAs to
enforce the constraint in a guaranteed manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9635) Silent startup failure with filesystem that does not support mmap
[
https://issues.apache.org/jira/browse/CASSANDRA-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605418#comment-14605418
]
Branimir Lambov commented on CASSANDRA-9635:
Is the commit log failure policy not working correctly, i.e. does the node fail
to reach the state it is supposed to after this happens? I believe a deadlock
waiting for allocation is to be expected as a result of the 'stop' policy.
Perhaps a good simple solution may be for the policy to start as 'die' until we
have done one allocation.
Silent startup failure with filesystem that does not support mmap
-
Key: CASSANDRA-9635
URL: https://issues.apache.org/jira/browse/CASSANDRA-9635
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Kevin McLaughlin
Assignee: Stefania
Fix For: 2.0.x
Attachments: c_tdump.txt
C* version 2.0.9.
When running C* in virtualbox on OS X via boot2docker with the data directory
on a shared volume from the host system (vboxfs), C* fails to start without
printing any errors.
I do not know if C* is supposed to support filesystems that do not support
mmap (does not appear so), however, I think the failure exposes a static
initialization deadlock
(http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html).
I believe the virtualbox bug is https://www.virtualbox.org/ticket/819.
Stacktrace of the deadlock is attached. When placing a t.printStackTrace()
between lines 115 and 116 in
https://github.com/apache/cassandra/blob/cassandra-2.0.9/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java,
the stack trace at startup is:
{quote}
DEBUG 21:16:54,716 Creating new commit log segment
/var/lib/cassandra/commitlog/CommitLog-3-1435007814714.log
FSWriteError in /var/lib/cassandra/commitlog/CommitLog-3-1435007814714.log
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:143)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.freshSegment(CommitLogSegment.java:90)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator.createFreshSegment(CommitLogAllocator.java:263)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator.access$500(CommitLogAllocator.java:50)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:109)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Invalid argument
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:893)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:133)
... 6 more
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9635) Silent startup failure with filesystem that does not support mmap
[
https://issues.apache.org/jira/browse/CASSANDRA-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605485#comment-14605485
]
Stefania commented on CASSANDRA-9635:
-
Thanks for your input. CommitFailurePolicy in 2.0 has only these values:
{code}
public static enum CommitFailurePolicy
{
stop,
stop_commit,
ignore,
}
{code}
I only tested stop but I don't think the other ones would be any different.
When was the die policy introduced and shall I back port it? I can also set it
to 'die' until we have the first segment, on all branches that it.
Silent startup failure with filesystem that does not support mmap
-
Key: CASSANDRA-9635
URL: https://issues.apache.org/jira/browse/CASSANDRA-9635
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Kevin McLaughlin
Assignee: Stefania
Fix For: 2.0.x
Attachments: c_tdump.txt
C* version 2.0.9.
When running C* in virtualbox on OS X via boot2docker with the data directory
on a shared volume from the host system (vboxfs), C* fails to start without
printing any errors.
I do not know if C* is supposed to support filesystems that do not support
mmap (does not appear so), however, I think the failure exposes a static
initialization deadlock
(http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html).
I believe the virtualbox bug is https://www.virtualbox.org/ticket/819.
Stacktrace of the deadlock is attached. When placing a t.printStackTrace()
between lines 115 and 116 in
https://github.com/apache/cassandra/blob/cassandra-2.0.9/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java,
the stack trace at startup is:
{quote}
DEBUG 21:16:54,716 Creating new commit log segment
/var/lib/cassandra/commitlog/CommitLog-3-1435007814714.log
FSWriteError in /var/lib/cassandra/commitlog/CommitLog-3-1435007814714.log
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:143)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.freshSegment(CommitLogSegment.java:90)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator.createFreshSegment(CommitLogAllocator.java:263)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator.access$500(CommitLogAllocator.java:50)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:109)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Invalid argument
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:893)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:133)
... 6 more
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9665) Improve handling of UDF and UDA metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605527#comment-14605527
]
Robert Stupp commented on CASSANDRA-9665:
-
+1 - feel free to commit :)
Improve handling of UDF and UDA metadata
Key: CASSANDRA-9665
URL: https://issues.apache.org/jira/browse/CASSANDRA-9665
Project: Cassandra
Issue Type: Sub-task
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Fix For: 3.0 beta 1
A while ago we decided to make all functions and types keyspace local, but
haven't updated our assumption in the code accordingly.
One consequence is that in addition to {{Schema}} and {{KSMetaData}} we got
ourselves a completely separate registry singleton for built-in functions,
UDFs, and UDAs - the {{Functions}} class.
The linked branch makes UDAs and UDFs be a part of {{KSMetaData}}, as they
should be, and gets rid of the old {{Functions}} class.
A new {{Functions}} class is introduced - an immutable container for a given
keyspace's functions, and all the definitions are now spread between the
keyspaces.
Additionally, this moves all the built-in functions to {{SystemKeyspace}}.
This sneaks in a bit of {{CASSANDRA-9425}}, makes {{CASSANDRA-9367}} easier,
and is a minore pre-requisite for a proper implementation of
{{CASSANDRA-6717}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9674) Reevaluate size of result/accumulator types of built in sum()+avg() functions
Robert Stupp created CASSANDRA-9674:
---
Summary: Reevaluate size of result/accumulator types of built in
sum()+avg() functions
Key: CASSANDRA-9674
URL: https://issues.apache.org/jira/browse/CASSANDRA-9674
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Fix For: 2.2.x
I'd like to propose to enlarge the accumulator and result type. Reason is
simply that an integer overflow is likely to occur especially for these
narrow types. Even just the {{sum()}} of just two {{tinyint}} of {{100}}
would return {{-56}}, which is just wrong.
Probably like
[this|http://www.postgresql.org/docs/9.1/static/functions-aggregate.html].
If we decide to do so, we should do it in 2.2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605539#comment-14605539 ] Jonathan Ellis commented on CASSANDRA-9318: --- * default timeout is 2s not 10, so actually fine in your example of 300MB vs 150MB/s x 2s * but we can easily set a higher limit on MS heap -- maybe as high as 1/8 heap as default which gives us a *lot* of room for 8GB heap * you don't see a complete halt until capacity's worth of requests timeout all at once, because you don't get an entire capacity load accepted at once. it's more continuous than discrete -- you pause until the oldest expire, accept more, pause until the oldest expire, etc. so you make slow progress as load shedding can free up memory. thus, load shedding is complementary to flow control. * aggressively load shedding for outlier nodes is a good idea that we should follow up on in another ticket. again, current behavior of continuing to accept requests until we fall over is worse than imposing flow control, so we should start with that [flow control] in 2.1 and make further improvements in 2.2. Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
[
https://issues.apache.org/jira/browse/CASSANDRA-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kuptsov updated CASSANDRA-9676:
Description:
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated by
the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
was:
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which regulated with
the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
-
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated
by the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8576) Primary Key Pushdown For Hadoop
[ https://issues.apache.org/jira/browse/CASSANDRA-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605771#comment-14605771 ] Jeremy Hanna commented on CASSANDRA-8576: - Is there anything else that needs to happen on this before committing? Primary Key Pushdown For Hadoop --- Key: CASSANDRA-8576 URL: https://issues.apache.org/jira/browse/CASSANDRA-8576 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Russell Alexander Spitzer Assignee: Alex Liu Fix For: 2.1.x Attachments: 8576-2.1-branch.txt, 8576-trunk.txt, CASSANDRA-8576-v2-2.1-branch.txt, CASSANDRA-8576-v3-2.1-branch.txt I've heard reports from several users that they would like to have predicate pushdown functionality for hadoop (Hive in particular) based services. Example usecase Table with wide partitions, one per customer Application team has HQL they would like to run on a single customer Currently time to complete scales with number of customers since Input Format can't pushdown primary key predicate Current implementation requires a full table scan (since it can't recognize that a single partition was specified) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9677) Refactor KSMetaData
Aleksey Yeschenko created CASSANDRA-9677:
Summary: Refactor KSMetaData
Key: CASSANDRA-9677
URL: https://issues.apache.org/jira/browse/CASSANDRA-9677
Project: Cassandra
Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
Fix For: 3.x
As part of CASSANDRA-9425 and a follow-up to CASSANDRA-9665, and a
pre-requisite for new schema change protocol, this ticket will do the following
1. Make {{UTMetaData}} immutable (new {{Types}} class)
2. Refactor handling of the {{CFMetaData}} map in {{KSMetaData}} (new
{{Tables}} class)
3. Factor out params into a separate class ({{KeyspaceParams}})
4. Rename and move {{KSMetaData}} to {{schema.KeyspaceMetadata}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9658) Re-enable memory-mapped index file reads on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605763#comment-14605763 ] Joshua McKenzie commented on CASSANDRA-9658: [~iamaleksey]: My initial assumption is that getting buffered close to parity w/mmap on Windows is going to be both much more programmer-hour intensive and much more invasive than getting mmap stabilized on Windows in time for 2.2.x stabilizing. I agree on the long-term goal of standardizing on a single read path; I'll do some stress-testing today to get an initial read on how much pain enabling mmap'ed I/O on Windows might cause us. [~stefania_alborghetti]: I don't think 7066 will actually be necessary for us after CASSANDRA-8535 and then CASSANDRA-8984, however I'll need to stress test the paths today to get a better feel for it post 8984. Let's sit tight on these test results w/mmap on Windows before taking any other steps to try and get buffered reads closer to parity right now on account of this ticket. Re-enable memory-mapped index file reads on Windows --- Key: CASSANDRA-9658 URL: https://issues.apache.org/jira/browse/CASSANDRA-9658 Project: Cassandra Issue Type: Improvement Reporter: Joshua McKenzie Assignee: Joshua McKenzie Labels: Windows, performance Fix For: 2.2.x It appears that the impact of buffered vs. memory-mapped index file reads has changed dramatically since last I tested. [Here's some results on various platforms we pulled together yesterday w/2.2-HEAD|https://docs.google.com/spreadsheets/d/1JaO2x7NsK4SSg_ZBqlfH0AwspGgIgFZ9wZ12fC4VZb0/edit#gid=0]. TL;DR: On linux we see a 40% hit in performance from 108k ops/sec on reads to 64.8k ops/sec. While surprising in itself, the really unexpected result (to me) is on Windows - with standard access we're getting 16.8k ops/second on our bare-metal perf boxes vs. 184.7k ops/sec with memory-mapped index files, an over 10-fold increase in throughput. While testing w/standard access, CPU's on the stress machine and C* node are both sitting 4%, network doesn't appear bottlenecked, resource monitor doesn't show anything interesting, and performance counters in the kernel show very little. Changes in thread count simply serve to increase median latency w/out impacting any other visible metric that we're measuring, so I'm at a loss as to why the disparity is so huge on the platform. The combination of my changes to get the 2.1 branch to behave on Windows along with [~benedict] and [~Stefania]'s changes in lifecycle and cleanup patterns on 2.2 should hopefully have us in a state where transitioning back to using memory-mapped I/O on Windows will only cause trouble on snapshot deletion. Fairly simple runs of stress w/compaction aren't popping up any obvious errors on file access or renaming - I'm going to do some much heavier testing (ccm multi-node clusters, long stress w/repair and compaction, etc) and see if there's any outstanding issues that need to be stamped out to call mmap'ed index files on Windows safe. The one thing we'll never be able to support is deletion of snapshots while a node is running and sstables are mapped, but for a 10x throughput increase I think users would be willing to make that sacrifice. The combination of the powercfg profile change, the kernel timer resolution, and memory-mapped index files are giving some pretty interesting performance numbers on EC2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
[
https://issues.apache.org/jira/browse/CASSANDRA-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9676:
---
Reproduced In: 2.0.15
Fix Version/s: 2.0.x
CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
-
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
Fix For: 2.0.x
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated
by the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-9064) [LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe table statement
[
https://issues.apache.org/jira/browse/CASSANDRA-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-9064:
-
Assignee: Benjamin Lerer (was: Adam Holmberg)
[LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe
table statement
Key: CASSANDRA-9064
URL: https://issues.apache.org/jira/browse/CASSANDRA-9064
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cassandra 2.1.3 on mac os x
Reporter: Sujeet Gholap
Assignee: Benjamin Lerer
Labels: cqlsh
Fix For: 2.2.0 rc2, 2.1.8
Here's how to reproduce:
1) Create a table with LeveledCompactionStrategy
CREATE keyspace foo WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor' : 3};
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH compaction = {'class': 'LeveledCompactionStrategy'};
2) Describe the table and save the output
cqlsh -e describe table foo.bar
Output should be something like
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH bloom_filter_fp_chance = 0.1
AND caching = '{keys:ALL, rows_per_partition:NONE}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy',
'max_threshold': '32'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
3) Save the output to repro.cql
4) Drop the table foo.bar
cqlsh -e drop table foo.bar
5) Run the create table statement we saved
cqlsh -f repro.cql
6) Expected: normal execution without an error
7) Reality:
ConfigurationException: ErrorMessage code=2300 [Query invalid because of
configuration issue] message=Properties specified [min_threshold,
max_threshold] are not understood by LeveledCompactionStrategy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9658) Re-enable memory-mapped index file reads on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605763#comment-14605763 ] Joshua McKenzie edited comment on CASSANDRA-9658 at 6/29/15 3:44 PM: - [~iamaleksey]: My initial assumption is that getting buffered close to parity w/mmap on Windows is going to be both much more programmer-hour intensive and much more invasive than getting mmap stabilized on Windows in time for 2.2.x stabilizing. I agree on the long-term goal of standardizing on a single read path; I'll do some stress-testing today to get an initial read on how much pain enabling mmap'ed I/O on Windows might cause us. [~stefania_alborghetti]: I don't think 7066 will actually be necessary for us (edit: specifically in this context of enabling mmap on Windows w/out access violations, not saying 7066 isn't necessary :)) after CASSANDRA-8535 and then CASSANDRA-8984, however I'll need to stress test the paths today to get a better feel for it post 8984. Let's sit tight on these test results w/mmap on Windows before taking any other steps to try and get buffered reads closer to parity right now on account of this ticket. was (Author: joshuamckenzie): [~iamaleksey]: My initial assumption is that getting buffered close to parity w/mmap on Windows is going to be both much more programmer-hour intensive and much more invasive than getting mmap stabilized on Windows in time for 2.2.x stabilizing. I agree on the long-term goal of standardizing on a single read path; I'll do some stress-testing today to get an initial read on how much pain enabling mmap'ed I/O on Windows might cause us. [~stefania_alborghetti]: I don't think 7066 will actually be necessary for us after CASSANDRA-8535 and then CASSANDRA-8984, however I'll need to stress test the paths today to get a better feel for it post 8984. Let's sit tight on these test results w/mmap on Windows before taking any other steps to try and get buffered reads closer to parity right now on account of this ticket. Re-enable memory-mapped index file reads on Windows --- Key: CASSANDRA-9658 URL: https://issues.apache.org/jira/browse/CASSANDRA-9658 Project: Cassandra Issue Type: Improvement Reporter: Joshua McKenzie Assignee: Joshua McKenzie Labels: Windows, performance Fix For: 2.2.x It appears that the impact of buffered vs. memory-mapped index file reads has changed dramatically since last I tested. [Here's some results on various platforms we pulled together yesterday w/2.2-HEAD|https://docs.google.com/spreadsheets/d/1JaO2x7NsK4SSg_ZBqlfH0AwspGgIgFZ9wZ12fC4VZb0/edit#gid=0]. TL;DR: On linux we see a 40% hit in performance from 108k ops/sec on reads to 64.8k ops/sec. While surprising in itself, the really unexpected result (to me) is on Windows - with standard access we're getting 16.8k ops/second on our bare-metal perf boxes vs. 184.7k ops/sec with memory-mapped index files, an over 10-fold increase in throughput. While testing w/standard access, CPU's on the stress machine and C* node are both sitting 4%, network doesn't appear bottlenecked, resource monitor doesn't show anything interesting, and performance counters in the kernel show very little. Changes in thread count simply serve to increase median latency w/out impacting any other visible metric that we're measuring, so I'm at a loss as to why the disparity is so huge on the platform. The combination of my changes to get the 2.1 branch to behave on Windows along with [~benedict] and [~Stefania]'s changes in lifecycle and cleanup patterns on 2.2 should hopefully have us in a state where transitioning back to using memory-mapped I/O on Windows will only cause trouble on snapshot deletion. Fairly simple runs of stress w/compaction aren't popping up any obvious errors on file access or renaming - I'm going to do some much heavier testing (ccm multi-node clusters, long stress w/repair and compaction, etc) and see if there's any outstanding issues that need to be stamped out to call mmap'ed index files on Windows safe. The one thing we'll never be able to support is deletion of snapshots while a node is running and sstables are mapped, but for a 10x throughput increase I think users would be willing to make that sacrifice. The combination of the powercfg profile change, the kernel timer resolution, and memory-mapped index files are giving some pretty interesting performance numbers on EC2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9522) Specify unset column ratios in cassandra-stress write
[
https://issues.apache.org/jira/browse/CASSANDRA-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605785#comment-14605785
]
Jim Witschey commented on CASSANDRA-9522:
-
Last he and I talked, [~tjake] proposed a {{insert_sparseness_distribution}}
parameter in the stress yaml that would allow you to set sparseness per
partition with a distribution specifier like {{fixed(50)}} or
{{uniform(40..60)}}. That'd work for me; is that still a workable change?
Specify unset column ratios in cassandra-stress write
-
Key: CASSANDRA-9522
URL: https://issues.apache.org/jira/browse/CASSANDRA-9522
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jim Witschey
Assignee: T Jake Luciani
Fix For: 3.0 beta 1
I'd like to be able to use stress to generate workloads with different
distributions of unset columns -- so, for instance, you could specify that
rows will have 70% unset columns, and on average, a 100-column row would
contain only 30 values.
This would help us test the new row formats introduced in 8099. There are a 2
different row formats, used depending on the ratio of set to unset columns,
and this feature would let us generate workloads that would be stored in each
of those formats.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9522) Specify unset column ratios in cassandra-stress write
[ https://issues.apache.org/jira/browse/CASSANDRA-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605791#comment-14605791 ] T Jake Luciani commented on CASSANDRA-9522: --- Yeah, working on this atm Specify unset column ratios in cassandra-stress write - Key: CASSANDRA-9522 URL: https://issues.apache.org/jira/browse/CASSANDRA-9522 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jim Witschey Assignee: T Jake Luciani Fix For: 3.0 beta 1 I'd like to be able to use stress to generate workloads with different distributions of unset columns -- so, for instance, you could specify that rows will have 70% unset columns, and on average, a 100-column row would contain only 30 values. This would help us test the new row formats introduced in 8099. There are a 2 different row formats, used depending on the ratio of set to unset columns, and this feature would let us generate workloads that would be stored in each of those formats. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9654) Failure to open sstable after upgrade to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605766#comment-14605766
]
Branimir Lambov commented on CASSANDRA-9654:
The sstables zip you attached is already corrupted (it does specify
LocalPartitioner as the partitioner for all except one of the sstables). Could
you zip up the contents at the previous step of the upgrade test?
Failure to open sstable after upgrade to trunk
--
Key: CASSANDRA-9654
URL: https://issues.apache.org/jira/browse/CASSANDRA-9654
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Philip Thompson
Assignee: Branimir Lambov
Fix For: 3.x
Attachments: node1.log, node2.log, node3.log, sstables.tar.gz
After upgrading a 3 node cluster on the path 1.2.19 - 2.0.16 - 2.1-head -
2.2-head - trunk
{code}
ERROR [SSTableBatchOpen:1] 2015-06-25 17:16:55,424 SSTableReader.java:435 -
Cannot open /tmp/dtest-Ibi6zm/test/node1/data/upgrade/cf/la-7-big;
partitioner org.apache.cassandra.dht.LocalPartitioner does not match system
partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the
default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you
will need to edit that to match your old partitioner if upgrading.
ERROR [SSTableBatchOpen:2] 2015-06-25 17:16:55,425 SSTableReader.java:435 -
Cannot open /tmp/dtest-Ibi6zm/test/node1/data/upgrade/cf/la-10-big;
partitioner org.apache.cassandra.dht.LocalPartitioner does not match system
partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the
default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you
will need to edit that to match your old partitioner if upgrading.
{code}
Node logs are attached.
To reproduce, you'll need to run the upgrade dtest as follows:
{{nosetests -sv
upgrade_through_versions_test.py:TestUpgradeThroughVersions.upgrade_test}}. I
don't have CI results for this yet, nor will I soon. To run this, you'll need
both JDK7 and JDK8 installed, for compilation reasons. Set the env vars
JAVA7_HOME and JAVA8_HOME, respectively. I'll work on finding an sstable that
represent the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605779#comment-14605779 ] Benedict commented on CASSANDRA-9318: - This still leaves some questions, of varying import and difficulty: * how can we easily block consumption of writes from clients without stopping reads? * how should we mandate (or encourage) native clients to behave: ** separate read/write connections? ** configurable blocking queue size for pending writes to avoid unbounded growth? ** should timeouts be from time of despatch, or from time of submission to local client? * will we implement this for thrift clients? Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8576) Primary Key Pushdown For Hadoop
[ https://issues.apache.org/jira/browse/CASSANDRA-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605806#comment-14605806 ] Jonathan Ellis edited comment on CASSANDRA-8576 at 6/29/15 4:01 PM: Let's keep 2.1 for bug fixes and commit this to 2.2. Can I get a 2.2 patch from Alex? (Edit: Piotr +1'd v3 already) was (Author: jbellis): Let's keep 2.1 for bug fixes and commit this to 2.2. Can I get a 2.2 patch from Alex? Primary Key Pushdown For Hadoop --- Key: CASSANDRA-8576 URL: https://issues.apache.org/jira/browse/CASSANDRA-8576 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Russell Alexander Spitzer Assignee: Alex Liu Fix For: 2.2.x Attachments: 8576-2.1-branch.txt, 8576-trunk.txt, CASSANDRA-8576-v2-2.1-branch.txt, CASSANDRA-8576-v3-2.1-branch.txt I've heard reports from several users that they would like to have predicate pushdown functionality for hadoop (Hive in particular) based services. Example usecase Table with wide partitions, one per customer Application team has HQL they would like to run on a single customer Currently time to complete scales with number of customers since Input Format can't pushdown primary key predicate Current implementation requires a full table scan (since it can't recognize that a single partition was specified) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8576) Primary Key Pushdown For Hadoop
[ https://issues.apache.org/jira/browse/CASSANDRA-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8576: -- Fix Version/s: (was: 2.1.x) 2.2.x Let's keep 2.1 for bug fixes and commit this to 2.2. Can I get a 2.2 patch from Alex? Primary Key Pushdown For Hadoop --- Key: CASSANDRA-8576 URL: https://issues.apache.org/jira/browse/CASSANDRA-8576 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Russell Alexander Spitzer Assignee: Alex Liu Fix For: 2.2.x Attachments: 8576-2.1-branch.txt, 8576-trunk.txt, CASSANDRA-8576-v2-2.1-branch.txt, CASSANDRA-8576-v3-2.1-branch.txt I've heard reports from several users that they would like to have predicate pushdown functionality for hadoop (Hive in particular) based services. Example usecase Table with wide partitions, one per customer Application team has HQL they would like to run on a single customer Currently time to complete scales with number of customers since Input Format can't pushdown primary key predicate Current implementation requires a full table scan (since it can't recognize that a single partition was specified) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8576) Primary Key Pushdown For Hadoop
[ https://issues.apache.org/jira/browse/CASSANDRA-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605809#comment-14605809 ] Aleksey Yeschenko commented on CASSANDRA-8576: -- bq. (Edit: Piotr +1'd v3 already) Doh, you are right. Primary Key Pushdown For Hadoop --- Key: CASSANDRA-8576 URL: https://issues.apache.org/jira/browse/CASSANDRA-8576 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Russell Alexander Spitzer Assignee: Alex Liu Fix For: 2.2.x Attachments: 8576-2.1-branch.txt, 8576-trunk.txt, CASSANDRA-8576-v2-2.1-branch.txt, CASSANDRA-8576-v3-2.1-branch.txt I've heard reports from several users that they would like to have predicate pushdown functionality for hadoop (Hive in particular) based services. Example usecase Table with wide partitions, one per customer Application team has HQL they would like to run on a single customer Currently time to complete scales with number of customers since Input Format can't pushdown primary key predicate Current implementation requires a full table scan (since it can't recognize that a single partition was specified) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605814#comment-14605814 ] Benedict commented on CASSANDRA-9318: - Do you mean within a single connection? I was under the impression we absolutely didn't want to stop readers? I disagree about not imposing _expectations_ on client implementations, so that users don't need to reason about each connector they use independently. Along with the protocol spec, other specs such as behaviour in these scenarios should really be spelled out. If clients want to do their own thing, there's not much we can do, but it's helpful for users to have an expectation of behaviour, and for implementors to be made aware of the potential problems their driver may encounter that they do not anticipate (and what everyone will expect them to do). Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE
[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605827#comment-14605827
]
Adam Holmberg commented on CASSANDRA-8005:
--
Revisiting this ticket as we look again at CASSANDRA-6717. We're now faced with
supporting multiple metadata implementations, *and* generating CQL from them. I
totally agree that toString is a misfeature on the client side, which is why I
am strongly in support of this ticket.
I think people expect to be able to DESC and reproduce schema in CQL,
independent of the metadata implementation. In the past CQL output has been
implemented in the driver. If the driver does not provide this, how would we
reproduce the schema? I think that is the job of the server.
Server-side DESCRIBE
Key: CASSANDRA-8005
URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Tyler Hobbs
Priority: Minor
Labels: client-impacting, cql3
The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
nearly identical implementations exist in many drivers. There are several
motivations for making {{DESCRIBE}} part of the CQL language:
* Eliminate the (fairly complex) duplicate implementations across drivers and
cqlsh
* Get closer to allowing drivers to not have to fetch the schema tables.
(Minor changes to prepared statements are also needed.)
* Have instantaneous support for new schema features in cqlsh. (You
currently have to update the bundled python driver.)
* Support writing out schemas where it makes sense. One good example of this
is backups. You need to restore the schema before restoring data in the case
of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9459) SecondaryIndex API redesign
[ https://issues.apache.org/jira/browse/CASSANDRA-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605831#comment-14605831 ] Sam Tunnicliffe commented on CASSANDRA-9459: At the moment, this is looking eminently doable on top of CASSANDRA-8099. In my WIP I have CASSANDRA-9041 working and CASSANDRA-7771 as close to working as possible without CASSANDRA-6717's changes to the underlying schema tables. In addition, I've reworked the main 2i API to make it primarily (CQL) row based, which should be a better fit for most of the known custom 2i implementations out there. Right now, the read both write paths (write time compaction) are basically working and I'm just troubleshooting some existing searcher issues on the main 8099 branch. Once I'm done with that I'll post a summary of the proposed new API for review while I get on with building out the ancillary parts (rebuild and so forth) and improving test coverage. As far as being able to utilise CQL internally in 2i implementations, it's not something I've looked at yet but I'm working on dummy index implementations to help validate the API, so I can use those to investigate. SecondaryIndex API redesign --- Key: CASSANDRA-9459 URL: https://issues.apache.org/jira/browse/CASSANDRA-9459 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Fix For: 3.0 beta 1 For some time now the index subsystem has been a pain point and in large part this is due to the way that the APIs and principal classes have grown organically over the years. It would be a good idea to conduct a wholesale review of the area and see if we can come up with something a bit more coherent. A few starting points: * There's a lot in AbstractPerColumnSecondaryIndex its subclasses which could be pulled up into SecondaryIndexSearcher (note that to an extent, this is done in CASSANDRA-8099). * SecondayIndexManager is overly complex and several of its functions should be simplified/re-examined. The handling of which columns are indexed and index selection on both the read and write paths are somewhat dense and unintuitive. * The SecondaryIndex class hierarchy is rather convoluted and could use some serious rework. There are a number of outstanding tickets which we should be able to roll into this higher level one as subtasks (but I'll defer doing that until getting into the details of the redesign): * CASSANDRA-7771 * CASSANDRA-8103 * CASSANDRA-9041 * CASSANDRA-4458 * CASSANDRA-8505 Whilst they're not hard dependencies, I propose that this be done on top of both CASSANDRA-8099 and CASSANDRA-6717. The former largely because the storage engine changes may facilitate a friendlier index API, but also because of the changes to SIS mentioned above. As for 6717, the changes to schema tables there will help facilitate CASSANDRA-7771. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9657) Hint table doing unnecessary compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9657:
---
Fix Version/s: 2.1.x
Hint table doing unnecessary compaction
---
Key: CASSANDRA-9657
URL: https://issues.apache.org/jira/browse/CASSANDRA-9657
Project: Cassandra
Issue Type: Bug
Environment: 2.1.7
Reporter: Jan Karlsson
Priority: Minor
Fix For: 2.1.x
I found some really strange behaviour. During the replay of a node I found
this in the log:
{code}INFO [CompactionExecutor:7] CompactionTask.java:271 Compacted 1
sstables to
[/var/lib/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-120,].
452,150,727 bytes to 452,150,727 (~100% of original) in 267,588ms =
1.611449MB/s. 1 total partitions merged to 1. Partition merge counts were
{1:1, }{code}
This happened multiple times until the hint replay was completed and the
sstables were removed.
I tried to replicate this by just starting up a cluster in ccm and killing a
node for a few minutes. I got the same behaviour then.
{Code}
INFO [CompactionExecutor:2] CompactionTask.java:270 - Compacted 1 sstables
to
[/home/ejankan/.ccm/hint/node3/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-2,].
65,570 bytes to 65,570 (~100% of original) in 600ms = 0.104221MB/s. 1
total partitions merged to 1. Partition merge counts were {1:1, }
{Code}
It seems weird to me that the file does not decrease in size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-9657) Hint table doing unnecessary compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson resolved CASSANDRA-9657.
Resolution: Not A Problem
[~Jan Karlsson], this will be fixed in 3.0, but unfortunately, for now it is
expected behavior.
Hint table doing unnecessary compaction
---
Key: CASSANDRA-9657
URL: https://issues.apache.org/jira/browse/CASSANDRA-9657
Project: Cassandra
Issue Type: Bug
Environment: 2.1.7
Reporter: Jan Karlsson
Priority: Minor
Fix For: 2.1.x
I found some really strange behaviour. During the replay of a node I found
this in the log:
{code}INFO [CompactionExecutor:7] CompactionTask.java:271 Compacted 1
sstables to
[/var/lib/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-120,].
452,150,727 bytes to 452,150,727 (~100% of original) in 267,588ms =
1.611449MB/s. 1 total partitions merged to 1. Partition merge counts were
{1:1, }{code}
This happened multiple times until the hint replay was completed and the
sstables were removed.
I tried to replicate this by just starting up a cluster in ccm and killing a
node for a few minutes. I got the same behaviour then.
{Code}
INFO [CompactionExecutor:2] CompactionTask.java:270 - Compacted 1 sstables
to
[/home/ejankan/.ccm/hint/node3/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-2,].
65,570 bytes to 65,570 (~100% of original) in 600ms = 0.104221MB/s. 1
total partitions merged to 1. Partition merge counts were {1:1, }
{Code}
It seems weird to me that the file does not decrease in size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
[
https://issues.apache.org/jira/browse/CASSANDRA-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605848#comment-14605848
]
Benedict commented on CASSANDRA-9676:
-
2.0 is EOL
CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
-
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
Fix For: 2.0.x
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated
by the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9678) help describe is missing the documentation for UDFs
Peter Halliday created CASSANDRA-9678: - Summary: help describe is missing the documentation for UDFs Key: CASSANDRA-9678 URL: https://issues.apache.org/jira/browse/CASSANDRA-9678 Project: Cassandra Issue Type: Improvement Reporter: Peter Halliday Priority: Minor On 2.1 when you type help describe, the documentation for describe types is missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8005) Server-side DESCRIBE
[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605867#comment-14605867
]
Jonathan Ellis edited comment on CASSANDRA-8005 at 6/29/15 4:32 PM:
bq. I believe in Postgres approach. What we need is a (versioned?) virtual
table set exposing a fixed and documented data dictionary that you could rely
on, that would map 1-1 to CQL syntax, more or less.
+1. Server should provide schema in a way humans and clients can meaningfully
introspect it. But it is not server's job to reverse engineer that into actual
CQL strings.
was (Author: jbellis):
bq. I believe in Postgres approach. What we need is a (versioned?) virtual
table set exposing a fixed and documented data dictionary that you could rely
on, that would map 1-1 to CQL syntax, more or less.
+1
Server-side DESCRIBE
Key: CASSANDRA-8005
URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Tyler Hobbs
Priority: Minor
Labels: client-impacting, cql3
The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
nearly identical implementations exist in many drivers. There are several
motivations for making {{DESCRIBE}} part of the CQL language:
* Eliminate the (fairly complex) duplicate implementations across drivers and
cqlsh
* Get closer to allowing drivers to not have to fetch the schema tables.
(Minor changes to prepared statements are also needed.)
* Have instantaneous support for new schema features in cqlsh. (You
currently have to update the bundled python driver.)
* Support writing out schemas where it makes sense. One good example of this
is backups. You need to restore the schema before restoring data in the case
of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8005) Server-side DESCRIBE
[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605867#comment-14605867
]
Jonathan Ellis edited comment on CASSANDRA-8005 at 6/29/15 4:32 PM:
bq. I believe in Postgres approach. What we need is a (versioned?) virtual
table set exposing a fixed and documented data dictionary that you could rely
on, that would map 1-1 to CQL syntax, more or less.
+1. Server should provide schema in a way humans and clients can meaningfully
introspect it. But it is not server's job to reverse engineer that into actual
CQL strings.
(Nor, IMO, should it be drivers' jobs. Time to deprecate that.)
was (Author: jbellis):
bq. I believe in Postgres approach. What we need is a (versioned?) virtual
table set exposing a fixed and documented data dictionary that you could rely
on, that would map 1-1 to CQL syntax, more or less.
+1. Server should provide schema in a way humans and clients can meaningfully
introspect it. But it is not server's job to reverse engineer that into actual
CQL strings.
Server-side DESCRIBE
Key: CASSANDRA-8005
URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Tyler Hobbs
Priority: Minor
Labels: client-impacting, cql3
The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
nearly identical implementations exist in many drivers. There are several
motivations for making {{DESCRIBE}} part of the CQL language:
* Eliminate the (fairly complex) duplicate implementations across drivers and
cqlsh
* Get closer to allowing drivers to not have to fetch the schema tables.
(Minor changes to prepared statements are also needed.)
* Have instantaneous support for new schema features in cqlsh. (You
currently have to update the bundled python driver.)
* Support writing out schemas where it makes sense. One good example of this
is backups. You need to restore the schema before restoring data in the case
of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9679) Don't rely on client CQL export for cqlsh DESC
Adam Holmberg created CASSANDRA-9679:
Summary: Don't rely on client CQL export for cqlsh DESC
Key: CASSANDRA-9679
URL: https://issues.apache.org/jira/browse/CASSANDRA-9679
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Adam Holmberg
Client CQL generation will be deprecated. Don't rely on metadata methods
{{as_cql_query}} or {{export_as_string}} for producing DESC output.
Background in CASSANDRA-8005
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605808#comment-14605808 ] Jonathan Ellis commented on CASSANDRA-9318: --- # We can't and we shouldn't # See Above # No Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9064) [LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe table statement
[
https://issues.apache.org/jira/browse/CASSANDRA-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605820#comment-14605820
]
Benjamin Lerer commented on CASSANDRA-9064:
---
The patch is
[here|https://github.com/apache/cassandra/compare/trunk...blerer:9064]
[LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe
table statement
Key: CASSANDRA-9064
URL: https://issues.apache.org/jira/browse/CASSANDRA-9064
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cassandra 2.1.3 on mac os x
Reporter: Sujeet Gholap
Assignee: Benjamin Lerer
Labels: cqlsh
Fix For: 2.2.0 rc2, 2.1.8
Here's how to reproduce:
1) Create a table with LeveledCompactionStrategy
CREATE keyspace foo WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor' : 3};
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH compaction = {'class': 'LeveledCompactionStrategy'};
2) Describe the table and save the output
cqlsh -e describe table foo.bar
Output should be something like
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH bloom_filter_fp_chance = 0.1
AND caching = '{keys:ALL, rows_per_partition:NONE}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy',
'max_threshold': '32'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
3) Save the output to repro.cql
4) Drop the table foo.bar
cqlsh -e drop table foo.bar
5) Run the create table statement we saved
cqlsh -f repro.cql
6) Expected: normal execution without an error
7) Reality:
ConfigurationException: ErrorMessage code=2300 [Query invalid because of
configuration issue] message=Properties specified [min_threshold,
max_threshold] are not understood by LeveledCompactionStrategy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9660) erro while adding a node to existing cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9660:
---
Description:
Hi,
We are trying to add a fresh node to existing cluster of cassandra. Currently
it has two nodes. While adding, it continue for a while and then node stops
after throwing following exception. I have restarted several times but it fails
every time.
{code}
ERROR 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Streaming error
occurred
java.io.IOException: net.jpountz.lz4.LZ4Exception: Error decoding offset 24114
of input buffer
at
org.apache.cassandra.io.compress.LZ4Compressor.uncompress(LZ4Compressor.java:93)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.compress.CompressedInputStream.decompress(CompressedInputStream.java:114)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.compress.CompressedInputStream.read(CompressedInputStream.java:92)
~[apache-cassandra-2.1.6.jar:2.1.6]
at java.io.InputStream.read(InputStream.java:170) ~[na:1.8.0_45]
at java.io.DataInputStream.readFully(DataInputStream.java:195)
~[na:1.8.0_45]
at java.io.DataInputStream.readLong(DataInputStream.java:416)
~[na:1.8.0_45]
at
org.apache.cassandra.utils.BytesReadTracker.readLong(BytesReadTracker.java:114)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:131)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.jar:na]
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:286)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.StreamReader.writeRow(StreamReader.java:156)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:89)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:48)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:250)
~[apache-cassandra-2.1.6.jar:2.1.6]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
Caused by: net.jpountz.lz4.LZ4Exception: Error decoding offset 24114 of input
buffer
at
net.jpountz.lz4.LZ4JNIFastDecompressor.decompress(LZ4JNIFastDecompressor.java:33)
~[lz4-1.2.0.jar:na]
at
org.apache.cassandra.io.compress.LZ4Compressor.uncompress(LZ4Compressor.java:88)
~[apache-cassandra-2.1.6.jar:2.1.6]
... 20 common frames omitted
INFO 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Session with
/192.168.36.81 is complete
WARN 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Stream failed
ERROR 11:13:54 Exception encountered during startup
java.lang.RuntimeException: Error during boostrap: Stream failed
at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1121)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:924)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:602)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:394)
[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:536)
[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:625)
[apache-cassandra-2.1.6.jar:2.1.6]
Caused by:
[jira] [Updated] (CASSANDRA-9660) erro while adding a node to existing cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9660:
---
Reproduced In: 2.1.6
Fix Version/s: 2.1.x
erro while adding a node to existing cluster
Key: CASSANDRA-9660
URL: https://issues.apache.org/jira/browse/CASSANDRA-9660
Project: Cassandra
Issue Type: Bug
Reporter: pankaj mishra
Fix For: 2.1.x
Hi,
We are trying to add a fresh node to existing cluster of cassandra. Currently
it has two nodes. While adding, it continue for a while and then node stops
after throwing following exception. I have restarted several times but it
fails every time.
{code}
ERROR 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Streaming error
occurred
java.io.IOException: net.jpountz.lz4.LZ4Exception: Error decoding offset
24114 of input buffer
at
org.apache.cassandra.io.compress.LZ4Compressor.uncompress(LZ4Compressor.java:93)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.compress.CompressedInputStream.decompress(CompressedInputStream.java:114)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.compress.CompressedInputStream.read(CompressedInputStream.java:92)
~[apache-cassandra-2.1.6.jar:2.1.6]
at java.io.InputStream.read(InputStream.java:170) ~[na:1.8.0_45]
at java.io.DataInputStream.readFully(DataInputStream.java:195)
~[na:1.8.0_45]
at java.io.DataInputStream.readLong(DataInputStream.java:416)
~[na:1.8.0_45]
at
org.apache.cassandra.utils.BytesReadTracker.readLong(BytesReadTracker.java:114)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:131)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.jar:na]
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:286)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.StreamReader.writeRow(StreamReader.java:156)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:89)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:48)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:250)
~[apache-cassandra-2.1.6.jar:2.1.6]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
Caused by: net.jpountz.lz4.LZ4Exception: Error decoding offset 24114 of input
buffer
at
net.jpountz.lz4.LZ4JNIFastDecompressor.decompress(LZ4JNIFastDecompressor.java:33)
~[lz4-1.2.0.jar:na]
at
org.apache.cassandra.io.compress.LZ4Compressor.uncompress(LZ4Compressor.java:88)
~[apache-cassandra-2.1.6.jar:2.1.6]
... 20 common frames omitted
INFO 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Session with
/192.168.36.81 is complete
WARN 11:13:54 [Stream #1856b120-1bea-11e5-86e3-4542c13bb31f] Stream failed
ERROR 11:13:54 Exception encountered during startup
java.lang.RuntimeException: Error during boostrap: Stream failed
at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1121)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:924)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:720)
~[apache-cassandra-2.1.6.jar:2.1.6]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:602)
[jira] [Updated] (CASSANDRA-9659) ServerErrorException: java.lang.AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9659:
---
Description:
An issue exists where a java.lang.AssertionError occurs for a select number of
read queries from Cassandra within our application.
It was suggested that a ticket be created to see if the error below is the same
as CASSANDRA-8949 which was fixed in version 2.1.5.
Here is a portion of the Cassandra log file where the exception occurs:
{code}
INFO [MemtableFlushWriter:50153] 2015-06-23 13:11:17,517 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
ReplayPosition(segmentId=1425054853780, position=8886361)
ERROR [SharedPool-Worker-1] 2015-06-23 13:11:29,047 Message.java:538 -
Unexpected exception during request; channel = [id: 0x8f1ca59e,
/10.30.43.68:33717 = /10.30.43.146:9042]javaa.lang.AssertionError:
[DecoratedKey(5747358200379796162,
6462346538352d653235382d343130352d616131612d346230396635353965666364),DecoratedKey(3303996443194009861,
34623632646562322d626234332d346661642d613263312d356334613233633037353932)]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:41)
~[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:34)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.makeIncludingKeyBounds(RangeSliceQueryPager.java:123)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.queryNextPage(RangeSliceQueryPager.java:74)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:87)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:219)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:134)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[apache-cassandra-2.1.3.jar:2.1.3]
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
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
[na:1.7.0_76]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-2.1.3.jar:2.1.3]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_76]
INFO [BatchlogTasks:1] 2015-06-23 13:12:17,521 ColumnFamilyStore.java:877 -
Enqueuing flush of batchlog: 27641 (0%) on-heap, 0 (0%) off-heap
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,522 Memtable.java:339 -
Writing Memtable-batchlog@297832842(22529 serialized bytes, 40 ops, 0%/0% of
on/off-heap limit)
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,523 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
ReplayPosition(segmentId=1425054853780, position=8948299)
{code}
was:
An issue exists where a java.lang.AssertionError occurs for a select number of
read queries from Cassandra within our application.
It was suggested that a ticket be created to see if the error below is the same
as CASSANDRA-8949 which was fixed in version 2.1.5.
Here is a portion of the Cassandra log file where the exception occurs:
INFO [MemtableFlushWriter:50153] 2015-06-23 13:11:17,517 Memtable.java:385 -
Completed flushing; nothing needed to
[jira] [Resolved] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
[
https://issues.apache.org/jira/browse/CASSANDRA-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson resolved CASSANDRA-9676.
Resolution: Duplicate
Fix Version/s: (was: 2.0.x)
2.1.6
CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
-
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
Fix For: 2.1.6
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated
by the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE
[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605863#comment-14605863
]
Aleksey Yeschenko commented on CASSANDRA-8005:
--
That's where we fundamentally disagree, then.
I believe in Postgres approach. What we need is a (versioned?) virtual table
set exposing a fixed and documented data dictionary that you could rely on,
that would map 1-1 to CQL syntax, more or less.
Let's see first how CASSANDRA-6717 and CASSANDRA-8099 pan out.
bq. We're now faced with supporting multiple metadata implementations, and
generating CQL from them.
Yes. For now. Long term, 2.2 metadata will be dropped from the drivers and just
one implementation will remain.
Server-side DESCRIBE
Key: CASSANDRA-8005
URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Tyler Hobbs
Priority: Minor
Labels: client-impacting, cql3
The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
nearly identical implementations exist in many drivers. There are several
motivations for making {{DESCRIBE}} part of the CQL language:
* Eliminate the (fairly complex) duplicate implementations across drivers and
cqlsh
* Get closer to allowing drivers to not have to fetch the schema tables.
(Minor changes to prepared statements are also needed.)
* Have instantaneous support for new schema features in cqlsh. (You
currently have to update the bundled python driver.)
* Support writing out schemas where it makes sense. One good example of this
is backups. You need to restore the schema before restoring data in the case
of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE
[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605867#comment-14605867
]
Jonathan Ellis commented on CASSANDRA-8005:
---
bq. I believe in Postgres approach. What we need is a (versioned?) virtual
table set exposing a fixed and documented data dictionary that you could rely
on, that would map 1-1 to CQL syntax, more or less.
+1
Server-side DESCRIBE
Key: CASSANDRA-8005
URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Tyler Hobbs
Priority: Minor
Labels: client-impacting, cql3
The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
nearly identical implementations exist in many drivers. There are several
motivations for making {{DESCRIBE}} part of the CQL language:
* Eliminate the (fairly complex) duplicate implementations across drivers and
cqlsh
* Get closer to allowing drivers to not have to fetch the schema tables.
(Minor changes to prepared statements are also needed.)
* Have instantaneous support for new schema features in cqlsh. (You
currently have to update the bundled python driver.)
* Support writing out schemas where it makes sense. One good example of this
is backups. You need to restore the schema before restoring data in the case
of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson reassigned CASSANDRA-9670:
--
Assignee: Philip Thompson (was: Joshua McKenzie)
Cannot run CQL scripts on Windows AND having error Ubuntu Linux
---
Key: CASSANDRA-9670
URL: https://issues.apache.org/jira/browse/CASSANDRA-9670
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: DataStax Community Edition
on Windows 7, 64 Bit and Ubuntu
Reporter: Sanjay Patel
Assignee: Philip Thompson
Fix For: 2.1.x
Attachments: cities.cql
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but
having same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
{code}
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte
0xc3 in position 18: ordinal not in range(128)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9670:
---
Labels: cqlsh (was: )
Cannot run CQL scripts on Windows AND having error Ubuntu Linux
---
Key: CASSANDRA-9670
URL: https://issues.apache.org/jira/browse/CASSANDRA-9670
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: DataStax Community Edition
on Windows 7, 64 Bit and Ubuntu
Reporter: Sanjay Patel
Assignee: Philip Thompson
Labels: cqlsh
Fix For: 2.1.x
Attachments: cities.cql
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but
having same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
{code}
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte
0xc3 in position 18: ordinal not in range(128)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605869#comment-14605869
]
Philip Thompson commented on CASSANDRA-9670:
Are you sure the shopping keyspace exists, in the first example?
Cannot run CQL scripts on Windows AND having error Ubuntu Linux
---
Key: CASSANDRA-9670
URL: https://issues.apache.org/jira/browse/CASSANDRA-9670
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: DataStax Community Edition
on Windows 7, 64 Bit and Ubuntu
Reporter: Sanjay Patel
Assignee: Philip Thompson
Labels: cqlsh
Fix For: 2.1.x
Attachments: cities.cql
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but
having same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
{code}
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte
0xc3 in position 18: ordinal not in range(128)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9659) ServerErrorException: java.lang.AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9659:
---
Assignee: Benjamin Lerer
Priority: Major (was: Critical)
ServerErrorException: java.lang.AssertionError
--
Key: CASSANDRA-9659
URL: https://issues.apache.org/jira/browse/CASSANDRA-9659
Project: Cassandra
Issue Type: Bug
Environment: CentOS 6.5
Cassandra 2.1.3
Reporter: Dave Decicco
Assignee: Benjamin Lerer
Fix For: 2.1.x
An issue exists where a java.lang.AssertionError occurs for a select number
of read queries from Cassandra within our application.
It was suggested that a ticket be created to see if the error below is the
same as CASSANDRA-8949 which was fixed in version 2.1.5.
Here is a portion of the Cassandra log file where the exception occurs:
{code}
INFO [MemtableFlushWriter:50153] 2015-06-23 13:11:17,517 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
ReplayPosition(segmentId=1425054853780, position=8886361)
ERROR [SharedPool-Worker-1] 2015-06-23 13:11:29,047 Message.java:538 -
Unexpected exception during request; channel = [id: 0x8f1ca59e,
/10.30.43.68:33717 = /10.30.43.146:9042]javaa.lang.AssertionError:
[DecoratedKey(5747358200379796162,
6462346538352d653235382d343130352d616131612d346230396635353965666364),DecoratedKey(3303996443194009861,
34623632646562322d626234332d346661642d613263312d356334613233633037353932)]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:41)
~[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:34)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.makeIncludingKeyBounds(RangeSliceQueryPager.java:123)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.queryNextPage(RangeSliceQueryPager.java:74)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:87)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:219)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:134)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[apache-cassandra-2.1.3.jar:2.1.3]
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
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) [na:1.7.0_76]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-2.1.3.jar:2.1.3]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_76]
INFO [BatchlogTasks:1] 2015-06-23 13:12:17,521 ColumnFamilyStore.java:877 -
Enqueuing flush of batchlog: 27641 (0%) on-heap, 0 (0%) off-heap
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,522 Memtable.java:339 -
Writing Memtable-batchlog@297832842(22529 serialized bytes, 40 ops, 0%/0% of
on/off-heap limit)
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,523 Memtable.java:385 -
Completed flushing; nothing needed to be retained.
[jira] [Commented] (CASSANDRA-8576) Primary Key Pushdown For Hadoop
[ https://issues.apache.org/jira/browse/CASSANDRA-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605803#comment-14605803 ] Aleksey Yeschenko commented on CASSANDRA-8576: -- Piotr's approval and +1 as the reviewer. Primary Key Pushdown For Hadoop --- Key: CASSANDRA-8576 URL: https://issues.apache.org/jira/browse/CASSANDRA-8576 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Russell Alexander Spitzer Assignee: Alex Liu Fix For: 2.1.x Attachments: 8576-2.1-branch.txt, 8576-trunk.txt, CASSANDRA-8576-v2-2.1-branch.txt, CASSANDRA-8576-v3-2.1-branch.txt I've heard reports from several users that they would like to have predicate pushdown functionality for hadoop (Hive in particular) based services. Example usecase Table with wide partitions, one per customer Application team has HQL they would like to run on a single customer Currently time to complete scales with number of customers since Input Format can't pushdown primary key predicate Current implementation requires a full table scan (since it can't recognize that a single partition was specified) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605817#comment-14605817 ] Jonathan Ellis commented on CASSANDRA-9318: --- https://issues.apache.org/jira/browse/CASSANDRA-9318?focusedCommentId=14604775page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14604775 Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9670:
---
Description:
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but having
same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3
in position 18: ordinal not in range(128)
was:
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but having
same error.
Attaching cities.cql for reference.
---
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File
[jira] [Updated] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9670:
---
Description:
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but having
same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
{code}
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3
in position 18: ordinal not in range(128)
{code}
was:
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but having
same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File
[jira] [Updated] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[ https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-9670: --- Reproduced In: 2.1.7 Fix Version/s: (was: 2.1.7) 2.1.x Cannot run CQL scripts on Windows AND having error Ubuntu Linux --- Key: CASSANDRA-9670 URL: https://issues.apache.org/jira/browse/CASSANDRA-9670 Project: Cassandra Issue Type: Bug Components: Core Environment: DataStax Community Edition on Windows 7, 64 Bit and Ubuntu Reporter: Sanjay Patel Fix For: 2.1.x Attachments: cities.cql After installation of 2.1.6 and 2.1.7 it is not possible to execute cql scripts, which were earlier executed on windows + Linux environment successfully. I have tried to install Python 2 latest version and try to execute, but having same error. Attaching cities.cql for reference. --- cqlsh source 'shoppoint_setup.cql' ; shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query] message=Keyspace 'shopping' does not exist shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57: ordinal not in range(128) cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not in range(128) cities.cql:14: Error starting import process: cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock cities.cql:14:can only join a started process cities.cql:16: Error starting import process: cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock cities.cql:16:can only join a started process Traceback (most recent call last): File string, line 1, in module File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in main prepare(preparation_data) File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in prepare Traceback (most recent call last): File string, line 1, in module file, path_name, etc = imp.find_module(main_name, dirs) ImportError: No module named cqlsh File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in main prepare(preparation_data) File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in prepare file, path_name, etc = imp.find_module(main_name, dirs) ImportError: No module named cqlsh shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18: ordinal not in range(128) ipcache.cql:28:ServerError: ErrorMessage code= [Server error] message=java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.io.FileNotFoundException: I:\var\lib\cassandra\data\syste m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db (The process cannot access the file because it is being used by another process) ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error] message=java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.io.FileNotFoundException: I:\var\lib\cassandra\d ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db (The process cannot access the file because it is being used by another process) shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14: ordinal not in range(128) - In one of Ubuntu development environment we have similar errors. - shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57: ordinal not in range(128) cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not in range(128) (corresponding line) COPY cities (city,country_code,state,isactive) FROM 'testdata/india_cities.csv' ; [19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18: ordinal not in range(128) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605825#comment-14605825 ] Benedict commented on CASSANDRA-9318: - My mistake, I clearly misread your earlier comment. I'm not sure I agree with that conclusion, but not strongly enough to prolong the discussion. So I guess that's that then. Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9670:
---
Assignee: Joshua McKenzie
Cannot run CQL scripts on Windows AND having error Ubuntu Linux
---
Key: CASSANDRA-9670
URL: https://issues.apache.org/jira/browse/CASSANDRA-9670
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: DataStax Community Edition
on Windows 7, 64 Bit and Ubuntu
Reporter: Sanjay Patel
Assignee: Joshua McKenzie
Fix For: 2.1.x
Attachments: cities.cql
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but
having same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
{code}
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte
0xc3 in position 18: ordinal not in range(128)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9659) ServerErrorException: java.lang.AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605835#comment-14605835
]
Philip Thompson commented on CASSANDRA-9659:
[~JoshuaMcKenzie], does this look like a duplicate of CASSANDRA-8949 to you?
ServerErrorException: java.lang.AssertionError
--
Key: CASSANDRA-9659
URL: https://issues.apache.org/jira/browse/CASSANDRA-9659
Project: Cassandra
Issue Type: Bug
Environment: CentOS 6.5
Cassandra 2.1.3
Reporter: Dave Decicco
Priority: Critical
An issue exists where a java.lang.AssertionError occurs for a select number
of read queries from Cassandra within our application.
It was suggested that a ticket be created to see if the error below is the
same as CASSANDRA-8949 which was fixed in version 2.1.5.
Here is a portion of the Cassandra log file where the exception occurs:
{code}
INFO [MemtableFlushWriter:50153] 2015-06-23 13:11:17,517 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
ReplayPosition(segmentId=1425054853780, position=8886361)
ERROR [SharedPool-Worker-1] 2015-06-23 13:11:29,047 Message.java:538 -
Unexpected exception during request; channel = [id: 0x8f1ca59e,
/10.30.43.68:33717 = /10.30.43.146:9042]javaa.lang.AssertionError:
[DecoratedKey(5747358200379796162,
6462346538352d653235382d343130352d616131612d346230396635353965666364),DecoratedKey(3303996443194009861,
34623632646562322d626234332d346661642d613263312d356334613233633037353932)]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:41)
~[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:34)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.makeIncludingKeyBounds(RangeSliceQueryPager.java:123)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.queryNextPage(RangeSliceQueryPager.java:74)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:87)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:219)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:134)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[apache-cassandra-2.1.3.jar:2.1.3]
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
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) [na:1.7.0_76]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-2.1.3.jar:2.1.3]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_76]
INFO [BatchlogTasks:1] 2015-06-23 13:12:17,521 ColumnFamilyStore.java:877 -
Enqueuing flush of batchlog: 27641 (0%) on-heap, 0 (0%) off-heap
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,522 Memtable.java:339 -
Writing Memtable-batchlog@297832842(22529 serialized bytes, 40 ops, 0%/0% of
on/off-heap limit)
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,523 Memtable.java:385 -
Completed flushing; nothing
[jira] [Commented] (CASSANDRA-9657) Hint table doing unnecessary compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605843#comment-14605843
]
Aleksey Yeschenko commented on CASSANDRA-9657:
--
Yes, unfortunately it is.
Hint table doing unnecessary compaction
---
Key: CASSANDRA-9657
URL: https://issues.apache.org/jira/browse/CASSANDRA-9657
Project: Cassandra
Issue Type: Bug
Environment: 2.1.7
Reporter: Jan Karlsson
Priority: Minor
Fix For: 2.1.x
I found some really strange behaviour. During the replay of a node I found
this in the log:
{code}INFO [CompactionExecutor:7] CompactionTask.java:271 Compacted 1
sstables to
[/var/lib/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-120,].
452,150,727 bytes to 452,150,727 (~100% of original) in 267,588ms =
1.611449MB/s. 1 total partitions merged to 1. Partition merge counts were
{1:1, }{code}
This happened multiple times until the hint replay was completed and the
sstables were removed.
I tried to replicate this by just starting up a cluster in ccm and killing a
node for a few minutes. I got the same behaviour then.
{Code}
INFO [CompactionExecutor:2] CompactionTask.java:270 - Compacted 1 sstables
to
[/home/ejankan/.ccm/hint/node3/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-2,].
65,570 bytes to 65,570 (~100% of original) in 600ms = 0.104221MB/s. 1
total partitions merged to 1. Partition merge counts were {1:1, }
{Code}
It seems weird to me that the file does not decrease in size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
[
https://issues.apache.org/jira/browse/CASSANDRA-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605841#comment-14605841
]
Philip Thompson commented on CASSANDRA-9676:
[~benedict], should 9071 have been fixed in 2.0 as well?
CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
-
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
Fix For: 2.0.x
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated
by the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9676) CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
[
https://issues.apache.org/jira/browse/CASSANDRA-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605859#comment-14605859
]
Philip Thompson commented on CASSANDRA-9676:
[~vkuptcov], you'll need to upgrade to 2.1.6 or higher to avoid this bug.
CQLSSTableWriter gives java.lang.AssertionError: Empty partition in C* 2.0.15
-
Key: CASSANDRA-9676
URL: https://issues.apache.org/jira/browse/CASSANDRA-9676
Project: Cassandra
Issue Type: Bug
Environment: cass 2.0.15
Reporter: Vladimir Kuptsov
Fix For: 2.1.6
I've the same issue as described in
https://issues.apache.org/jira/browse/CASSANDRA-9071
As I can understand it happens during the buffer flush, which size regulated
by the withBufferSizeInMB() method call in
{code}
CQLSSTableWriter
.builder()
.inDirectory(createOutputDir())
.forTable(metadata.schema)
.using(insertStatement)
.withBufferSizeInMB(128)
.build()
{code}
For example, when I use 128 Mb buffer, it fails after 210 000 csv lines
processed. On 3Mb buffer it fails after 10 000 lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9659) ServerErrorException: java.lang.AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9659:
---
Reproduced In: 2.1.3
Fix Version/s: 2.1.x
ServerErrorException: java.lang.AssertionError
--
Key: CASSANDRA-9659
URL: https://issues.apache.org/jira/browse/CASSANDRA-9659
Project: Cassandra
Issue Type: Bug
Environment: CentOS 6.5
Cassandra 2.1.3
Reporter: Dave Decicco
Priority: Critical
Fix For: 2.1.x
An issue exists where a java.lang.AssertionError occurs for a select number
of read queries from Cassandra within our application.
It was suggested that a ticket be created to see if the error below is the
same as CASSANDRA-8949 which was fixed in version 2.1.5.
Here is a portion of the Cassandra log file where the exception occurs:
{code}
INFO [MemtableFlushWriter:50153] 2015-06-23 13:11:17,517 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
ReplayPosition(segmentId=1425054853780, position=8886361)
ERROR [SharedPool-Worker-1] 2015-06-23 13:11:29,047 Message.java:538 -
Unexpected exception during request; channel = [id: 0x8f1ca59e,
/10.30.43.68:33717 = /10.30.43.146:9042]javaa.lang.AssertionError:
[DecoratedKey(5747358200379796162,
6462346538352d653235382d343130352d616131612d346230396635353965666364),DecoratedKey(3303996443194009861,
34623632646562322d626234332d346661642d613263312d356334613233633037353932)]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:41)
~[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:34)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.makeIncludingKeyBounds(RangeSliceQueryPager.java:123)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.queryNextPage(RangeSliceQueryPager.java:74)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:87)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:219)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:134)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[apache-cassandra-2.1.3.jar:2.1.3]
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
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) [na:1.7.0_76]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-2.1.3.jar:2.1.3]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_76]
INFO [BatchlogTasks:1] 2015-06-23 13:12:17,521 ColumnFamilyStore.java:877 -
Enqueuing flush of batchlog: 27641 (0%) on-heap, 0 (0%) off-heap
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,522 Memtable.java:339 -
Writing Memtable-batchlog@297832842(22529 serialized bytes, 40 ops, 0%/0% of
on/off-heap limit)
INFO [MemtableFlushWriter:50154] 2015-06-23 13:12:17,523 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
[jira] [Created] (CASSANDRA-9680) Update CQL version
Sylvain Lebresne created CASSANDRA-9680: --- Summary: Update CQL version Key: CASSANDRA-9680 URL: https://issues.apache.org/jira/browse/CASSANDRA-9680 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Tyler Hobbs Fix For: 2.2.0 rc2 I think we haven't upgraded the CQL spec version for 2.2 as far as I can tell. I say we should call it CQL 3.3. [~thobbs] Can you look at upgrading the version in the code and the doc? Listing the actual changes in the doc changelog would be awesome too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605817#comment-14605817 ] Jonathan Ellis edited comment on CASSANDRA-9318 at 6/29/15 4:11 PM: https://issues.apache.org/jira/browse/CASSANDRA-9318?focusedCommentId=14604775page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14604775 bq. [It is not] a good idea to try to allow extra reads when write capacity is full or vice versa. They both ultimately use the same resources (cpu, heap, disk i/o). was (Author: jbellis): https://issues.apache.org/jira/browse/CASSANDRA-9318?focusedCommentId=14604775page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14604775 [It is not] a good idea to try to allow extra reads when write capacity is full or vice versa. They both ultimately use the same resources (cpu, heap, disk i/o). Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605817#comment-14605817 ] Jonathan Ellis edited comment on CASSANDRA-9318 at 6/29/15 4:10 PM: https://issues.apache.org/jira/browse/CASSANDRA-9318?focusedCommentId=14604775page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14604775 [It is not] a good idea to try to allow extra reads when write capacity is full or vice versa. They both ultimately use the same resources (cpu, heap, disk i/o). was (Author: jbellis): https://issues.apache.org/jira/browse/CASSANDRA-9318?focusedCommentId=14604775page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14604775 Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9657) Hint table doing unnecessary compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605836#comment-14605836
]
Philip Thompson commented on CASSANDRA-9657:
[~iamaleksey], is this expected behavior?
Hint table doing unnecessary compaction
---
Key: CASSANDRA-9657
URL: https://issues.apache.org/jira/browse/CASSANDRA-9657
Project: Cassandra
Issue Type: Bug
Environment: 2.1.7
Reporter: Jan Karlsson
Priority: Minor
Fix For: 2.1.x
I found some really strange behaviour. During the replay of a node I found
this in the log:
{code}INFO [CompactionExecutor:7] CompactionTask.java:271 Compacted 1
sstables to
[/var/lib/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-120,].
452,150,727 bytes to 452,150,727 (~100% of original) in 267,588ms =
1.611449MB/s. 1 total partitions merged to 1. Partition merge counts were
{1:1, }{code}
This happened multiple times until the hint replay was completed and the
sstables were removed.
I tried to replicate this by just starting up a cluster in ccm and killing a
node for a few minutes. I got the same behaviour then.
{Code}
INFO [CompactionExecutor:2] CompactionTask.java:270 - Compacted 1 sstables
to
[/home/ejankan/.ccm/hint/node3/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/system-hints-ka-2,].
65,570 bytes to 65,570 (~100% of original) in 600ms = 0.104221MB/s. 1
total partitions merged to 1. Partition merge counts were {1:1, }
{Code}
It seems weird to me that the file does not decrease in size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9659) ServerErrorException: java.lang.AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605872#comment-14605872
]
Joshua McKenzie commented on CASSANDRA-9659:
Don't think so - 8949 would have been a silent drop if someone misused the API
internally. This looks like an incorrect bound being created during a select
statement creation as it's failing on the assertion in the constructor:
{noformat}
public Bounds(T left, T right, IPartitioner partitioner)
{
super(left, right, partitioner);
// unlike a Range, a Bounds may not wrap
assert left.compareTo(right) = 0 || right.isMinimum(partitioner) : [
+ left + , + right + ];
}
{noformat}
ServerErrorException: java.lang.AssertionError
--
Key: CASSANDRA-9659
URL: https://issues.apache.org/jira/browse/CASSANDRA-9659
Project: Cassandra
Issue Type: Bug
Environment: CentOS 6.5
Cassandra 2.1.3
Reporter: Dave Decicco
Priority: Critical
An issue exists where a java.lang.AssertionError occurs for a select number
of read queries from Cassandra within our application.
It was suggested that a ticket be created to see if the error below is the
same as CASSANDRA-8949 which was fixed in version 2.1.5.
Here is a portion of the Cassandra log file where the exception occurs:
{code}
INFO [MemtableFlushWriter:50153] 2015-06-23 13:11:17,517 Memtable.java:385 -
Completed flushing; nothing needed to be retained. Commitlog position was
ReplayPosition(segmentId=1425054853780, position=8886361)
ERROR [SharedPool-Worker-1] 2015-06-23 13:11:29,047 Message.java:538 -
Unexpected exception during request; channel = [id: 0x8f1ca59e,
/10.30.43.68:33717 = /10.30.43.146:9042]javaa.lang.AssertionError:
[DecoratedKey(5747358200379796162,
6462346538352d653235382d343130352d616131612d346230396635353965666364),DecoratedKey(3303996443194009861,
34623632646562322d626234332d346661642d613263312d356334613233633037353932)]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:41)
~[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.dht.Bounds.init(Bounds.java:34)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.makeIncludingKeyBounds(RangeSliceQueryPager.java:123)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.queryNextPage(RangeSliceQueryPager.java:74)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:87)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:219)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:134)
~[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[apache-cassandra-2.1.3.jar:2.1.3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[apache-cassandra-2.1.3.jar:2.1.3]
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
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) [na:1.7.0_76]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[apache-cassandra-2.1.3.jar:2.1.3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-2.1.3.jar:2.1.3]
at java.lang.Thread.run(Unknown Source)
[jira] [Commented] (CASSANDRA-8099) Refactor and modernize the storage engine
[
https://issues.apache.org/jira/browse/CASSANDRA-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605893#comment-14605893
]
Sylvain Lebresne commented on CASSANDRA-8099:
-
I've force-pushed a rebased version of the branch (still
[here|https://github.com/pcmanus/cassandra/tree/8099]). Since my last update,
on top of a number of fixes, I've finished moved the {{OpOrder}} out of the
iterators close and I've update the range tombstone code to used specific
boundaries marker as discussed above (I've also included Branamir's branch with
it's nits and fixed most others). I haven't had the time to upgrade
Branamir's test however and so for the sake of compilation I've currently
removed it. If you could have a look at rebasing you test [~blambov], that
would be very greatly appreciated as you're more familiar with it.
There is still a number of work to be done on this ticket, but the bulk of it
is reasonably stable, and outside of some of the backward compatibility code
the branch is generally functional. And we're starting to have tickets that are
based on this and are ready (or almost are), tickets that won't be impacted too
much by the remaining parts of this (which include the refactoring of the
flyweight-based implementation that I'm going to focus on now, the wire
backward compatibility code Tyler is working on and some general testing/bug
fixing).
So, based on some offline discussion, I suggest committing the current branch
to trunk. I won't close this ticket just yet and continue fixing the remaining
things, but it'll allow other tickets to synchronize on this and will generally
help get more eyes on this by necessity.
And I'm planning to commit this tomorrow-ish (my european tomorrow), so if you
have a strong objection to this (again, we're not closing the ticket and
committing it don't mean it can't change), please speak quickly.
Refactor and modernize the storage engine
-
Key: CASSANDRA-8099
URL: https://issues.apache.org/jira/browse/CASSANDRA-8099
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 3.0 beta 1
Attachments: 8099-nit
The current storage engine (which for this ticket I'll loosely define as the
code implementing the read/write path) is suffering from old age. One of the
main problem is that the only structure it deals with is the cell, which
completely ignores the more high level CQL structure that groups cell into
(CQL) rows.
This leads to many inefficiencies, like the fact that during a reads we have
to group cells multiple times (to count on replica, then to count on the
coordinator, then to produce the CQL resultset) because we forget about the
grouping right away each time (so lots of useless cell names comparisons in
particular). But outside inefficiencies, having to manually recreate the CQL
structure every time we need it for something is hindering new features and
makes the code more complex that it should be.
Said storage engine also has tons of technical debt. To pick an example, the
fact that during range queries we update {{SliceQueryFilter.count}} is pretty
hacky and error prone. Or the overly complex ways {{AbstractQueryPager}} has
to go into to simply remove the last query result.
So I want to bite the bullet and modernize this storage engine. I propose to
do 2 main things:
# Make the storage engine more aware of the CQL structure. In practice,
instead of having partitions be a simple iterable map of cells, it should be
an iterable list of row (each being itself composed of per-column cells,
though obviously not exactly the same kind of cell we have today).
# Make the engine more iterative. What I mean here is that in the read path,
we end up reading all cells in memory (we put them in a ColumnFamily object),
but there is really no reason to. If instead we were working with iterators
all the way through, we could get to a point where we're basically
transferring data from disk to the network, and we should be able to reduce
GC substantially.
Please note that such refactor should provide some performance improvements
right off the bat but it's not it's primary goal either. It's primary goal is
to simplify the storage engine and adds abstraction that are better suited to
further optimizations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9670) Cannot run CQL scripts on Windows AND having error Ubuntu Linux
[
https://issues.apache.org/jira/browse/CASSANDRA-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605922#comment-14605922
]
Sanjay Patel commented on CASSANDRA-9670:
-
Yes, it does exist. In main script i am dropping and creating again. All other
tables are created succesfully.
but having problem with data import. Same scripts runs in all environment
+server seccessfully with 2.0.7.
Cannot run CQL scripts on Windows AND having error Ubuntu Linux
---
Key: CASSANDRA-9670
URL: https://issues.apache.org/jira/browse/CASSANDRA-9670
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: DataStax Community Edition
on Windows 7, 64 Bit and Ubuntu
Reporter: Sanjay Patel
Assignee: Philip Thompson
Labels: cqlsh
Fix For: 2.1.x
Attachments: cities.cql
After installation of 2.1.6 and 2.1.7 it is not possible to execute cql
scripts, which were earlier executed on windows + Linux environment
successfully.
I have tried to install Python 2 latest version and try to execute, but
having same error.
Attaching cities.cql for reference.
---
{code}
cqlsh source 'shoppoint_setup.cql' ;
shoppoint_setup.cql:16:InvalidRequest: code=2200 [Invalid query]
message=Keyspace 'shopping' does not exist
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
cities.cql:14:
Error starting import process:
cities.cql:14:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:14:can only join a started process
cities.cql:16:
Error starting import process:
cities.cql:16:Can't pickle type 'thread.lock': it's not found as thread.lock
cities.cql:16:can only join a started process
Traceback (most recent call last):
File string, line 1, in module
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
Traceback (most recent call last):
File string, line 1, in module
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
File I:\programm\python2710\lib\multiprocessing\forking.py, line 380, in
main
prepare(preparation_data)
File I:\programm\python2710\lib\multiprocessing\forking.py, line 489, in
prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named cqlsh
shoppoint_setup.cql:663:'ascii' codec can't decode byte 0xc3 in position 18:
ordinal not in range(128)
ipcache.cql:28:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\data\syste
m\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-ka-300-Data.db
(The process cannot access the file because it is being used by another
process)
ccavn_bulkupdate.cql:75:ServerError: ErrorMessage code= [Server error]
message=java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: java.io.FileNotFoundException:
I:\var\lib\cassandra\d
ata\system\schema_columns-296e9c049bec3085827dc17d3df2122a\system-schema_columns-tmplink-ka-339-Data.db
(The process cannot access the file because it is being used by another
process)
shoppoint_setup.cql:680:'ascii' codec can't decode byte 0xe2 in position 14:
ordinal not in range(128){code}
-
In one of Ubuntu development environment we have similar errors.
-
{code}
shoppoint_setup.cql:647:'ascii' codec can't decode byte 0xc3 in position 57:
ordinal not in range(128)
cities.cql:9:'ascii' codec can't decode byte 0xc3 in position 51: ordinal not
in range(128)
(corresponding line) COPY cities (city,country_code,state,isactive) FROM
'testdata/india_cities.csv' ;
[19:53:18] j.basu: shoppoint_setup.cql:663:'ascii' codec can't decode byte
0xc3 in position 18: ordinal not in range(128)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
mlowicki created CASSANDRA-9681:
---
Summary: Memtable heap size grows and many long GC pauses are
triggered
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Priority: Critical
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done that
and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
[
https://issues.apache.org/jira/browse/CASSANDRA-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated CASSANDRA-9681:
Description:
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done that
and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
was:
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done that
and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Memtable heap size grows and many long GC pauses are triggered
--
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Priority: Critical
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done
that and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
[
https://issues.apache.org/jira/browse/CASSANDRA-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated CASSANDRA-9681:
Description:
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done that
and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Used memory on boxes where {{AllMemtabelesHeapSize}} grows, stays at the same
level -
https://www.dropbox.com/s/tes9abykixs86rf/Screenshot%202015-06-29%2019.37.52.png?dl=0.
was:
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done that
and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Memtable heap size grows and many long GC pauses are triggered
--
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Priority: Critical
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done
that and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Used memory on boxes where {{AllMemtabelesHeapSize}} grows, stays at the same
level -
https://www.dropbox.com/s/tes9abykixs86rf/Screenshot%202015-06-29%2019.37.52.png?dl=0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
[
https://issues.apache.org/jira/browse/CASSANDRA-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9681:
---
Reproduced In: 2.1.7
Fix Version/s: 2.1.x
Memtable heap size grows and many long GC pauses are triggered
--
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Priority: Critical
Fix For: 2.1.x
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done
that and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Used memory on boxes where {{AllMemtabelesHeapSize}} grows, stays at the same
level -
https://www.dropbox.com/s/tes9abykixs86rf/Screenshot%202015-06-29%2019.37.52.png?dl=0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9678) help describe is missing the documentation for UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606624#comment-14606624 ] Aleksey Yeschenko commented on CASSANDRA-9678: -- Are you sure you mean UDFs or UDTs? UDFs are new to 2.2. help describe is missing the documentation for UDFs --- Key: CASSANDRA-9678 URL: https://issues.apache.org/jira/browse/CASSANDRA-9678 Project: Cassandra Issue Type: Improvement Reporter: Peter Halliday Priority: Minor Labels: cqlsh Fix For: 2.1.x On 2.1 when you type help describe, the documentation for describe types is missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8630) Faster sequential IO (on compaction, streaming, etc)
[ https://issues.apache.org/jira/browse/CASSANDRA-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8630: -- Assignee: Stefania (was: Oleg Anastasyev) Faster sequential IO (on compaction, streaming, etc) Key: CASSANDRA-8630 URL: https://issues.apache.org/jira/browse/CASSANDRA-8630 Project: Cassandra Issue Type: Improvement Components: Core, Tools Reporter: Oleg Anastasyev Assignee: Stefania Labels: compaction, performance Fix For: 3.x Attachments: 8630-FasterSequencialReadsAndWrites.txt, cpu_load.png When node is doing a lot of sequencial IO (streaming, compacting, etc) a lot of CPU is lost in calls to RAF's int read() and DataOutputStream's write(int). This is because default implementations of readShort,readLong, etc as well as their matching write* are implemented with numerous calls of byte by byte read and write. This makes a lot of syscalls as well. A quick microbench shows than just reimplementation of these methods in either way gives 8x speed increase. A patch attached implements RandomAccessReader.readType and SequencialWriter.writeType methods in more efficient way. I also eliminated some extra byte copies in CompositeType.split and ColumnNameHelper.maxComponents, which were on my profiler's hotspot method list during tests. A stress tests on my laptop show that this patch makes compaction 25-30% faster on uncompressed sstables and 15% faster for compressed ones. A deployment to production shows much less CPU load for compaction. (I attached a cpu load graph from one of our production, orange is niced CPU load - i.e. compaction; yellow is user - i.e. not compaction related tasks) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
[ https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606685#comment-14606685 ] Jonathan Ellis commented on CASSANDRA-7392: --- I'm just envisioning here worker-thread checks to drop a request-in-progress. Fine with coordinator timing out normally, no need for extra work in StorageProxy as a first step. Abort in-progress queries that time out --- Key: CASSANDRA-7392 URL: https://issues.apache.org/jira/browse/CASSANDRA-7392 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Stefania Fix For: 3.x Currently we drop queries that time out before we get to them (because node is overloaded) but not queries that time out while being processed. (Particularly common for index queries on data that shouldn't be indexed.) Adding the latter and logging when we have to interrupt one gets us a poor man's slow query log for free. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605345#comment-14605345 ] Benedict commented on CASSANDRA-9318: - bq. I think you're \[Benedict\] overselling how scary it is to stop reading new requests until we can free up some memory from MS. The problem is that freeing up memory can be constrained by one or a handful of _dead_ nodes. We can not only stop accepting work, but significantly reduce cluster throughput as a result of a *single* timed-out node. I'm not overselling anything, although I may have a different risk analysis than you do. Take a simple mathematical thought experiment: we have a four node cluster (pretty common), with RF=3, serving 100kop/s per coordinator; these operations in memory occupy around 2K as a Mutation (again, pretty typical). Ordinary round-trip time is 10ms (also, pretty typical). So, under normal load we would see around 2Mb of data maintained for our queries in-flight across the cluster. But now one node goes down. This node is a peer for 3/4 of all writes to the cluster, so we see 150Mb/s of data accumulate in each coordinator. Our limit is probably no more than 300Mb (probably lower). Our timeout is 10s. So we now have 8s during which nothing can be done, across the cluster, due to one node's death. After that 8s has elapsed, we get another flurry. Then another 8s of nothing. Even with a CL of ONE. This really is fundamentally opposed to the whole idea of Cassandra, and I cannot emphasize how much I am against it except as a literal last resort when all other strategies have failed. bq. Hinting is better than leaving things in an unknown state but it's not something we should opt users into if we have a better option, since it basically turns the write into CL.ANY. I was under the impression we had moved to talking about ACK'd writes. I'm not suggesting we ack with success to the handler. What we do with unack'd writes is actually less important, and we have a much freer reign with. We could throw OE. We could block, as you suggest, since these should be more evenly distributed. However I would prefer we do both, i.e., when we run out of room in the coordinator, we should look to see if there are any nodes that have well in excess of their fair share of entries waiting for a response. Let's call these nodes N # if N=0, we block consumption of new writes, as you propose. # otherwise, we first evict those that have been ACK'd to the client and can be safely hinted (and hint them) # if this isn't enough, we evict handlers that, if all N were to fail, would break the CL we are waiting on, and we throw OE step 3 is necessary both for CL.ALL, and the scenario where 2 failing nodes have significant overlap Bound the number of in-flight requests at the coordinator - Key: CASSANDRA-9318 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 Project: Cassandra Issue Type: Improvement Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 2.1.x, 2.2.x It's possible to somewhat bound the amount of load accepted into the cluster by bounding the number of in-flight requests and request bytes. An implementation might do something like track the number of outstanding bytes and requests and if it reaches a high watermark disable read on client connections until it goes back below some low watermark. Need to make sure that disabling read on the client connection won't introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9064) [LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe table statement
[
https://issues.apache.org/jira/browse/CASSANDRA-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606151#comment-14606151
]
Benjamin Lerer commented on CASSANDRA-9064:
---
The unit tests results are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9064-testall/lastCompletedBuild/testReport/]
and the DTests results are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9064-dtest/lastCompletedBuild/testReport/]
[LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe
table statement
Key: CASSANDRA-9064
URL: https://issues.apache.org/jira/browse/CASSANDRA-9064
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cassandra 2.1.3 on mac os x
Reporter: Sujeet Gholap
Assignee: Benjamin Lerer
Labels: cqlsh
Fix For: 2.2.0 rc2, 2.1.8
Here's how to reproduce:
1) Create a table with LeveledCompactionStrategy
CREATE keyspace foo WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor' : 3};
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH compaction = {'class': 'LeveledCompactionStrategy'};
2) Describe the table and save the output
cqlsh -e describe table foo.bar
Output should be something like
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH bloom_filter_fp_chance = 0.1
AND caching = '{keys:ALL, rows_per_partition:NONE}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy',
'max_threshold': '32'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
3) Save the output to repro.cql
4) Drop the table foo.bar
cqlsh -e drop table foo.bar
5) Run the create table statement we saved
cqlsh -f repro.cql
6) Expected: normal execution without an error
7) Reality:
ConfigurationException: ErrorMessage code=2300 [Query invalid because of
configuration issue] message=Properties specified [min_threshold,
max_threshold] are not understood by LeveledCompactionStrategy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
[
https://issues.apache.org/jira/browse/CASSANDRA-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated CASSANDRA-9681:
Comment: was deleted
(was: I'll get heap dump probably tomorrow then as nodes have been restarted ~2
hours ago.)
Memtable heap size grows and many long GC pauses are triggered
--
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Assignee: Benedict
Priority: Critical
Fix For: 2.1.x
Attachments: cassandra.yaml, system.log.6.zip, system.log.7.zip,
system.log.8.zip, system.log.9.zip
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done
that and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Used memory on boxes where {{AllMemtabelesHeapSize}} grows, stays at the same
level -
https://www.dropbox.com/s/tes9abykixs86rf/Screenshot%202015-06-29%2019.37.52.png?dl=0.
Replication factor is set to 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
[
https://issues.apache.org/jira/browse/CASSANDRA-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606170#comment-14606170
]
Benedict commented on CASSANDRA-9681:
-
So, for posterity, I ran the following bash script for analysing the logs:
{code}
grep -E Completed flushing|Enqueuing flush of ([^:]+): [0-9]+ \(([0-9]+)%\)
system.log.2* | grep -v compactions_in_progress | sed -r s@.* - (.*)@\1@ |
sed -r s@Completed flushing .*-([^-]+)-ka-[0-9]+-Data.db.*@completed \1@ |
sed -r 's@Enqueuing flush of ([^ :]+): [0-9]+ \(([0-9]+)%.*@started \1 \2@' |
awk '{ if ($1 == started) { total[$2] += $3; list[$2][end[$2]] = $3;
end[$2]++; } else { total[$2] -= list[$2][start[$2]]; delete
list[$2][start[$2]]; start[$2]++; } print(total: total[$2] $0); }' | sort
| less
{code}
This indicates flushing is happening as expected, and staying well within the
bounds that are supposed to be enforced. These same numbers feed into those
that are reported via JMX. In fact, they should be strictly greater than that
returned by JMX, since JMX only reports the live memtables. So the numbers that
suggest you're exceeding your memtable space limits are hard to explain.
The heap dump will no doubt help a great deal.
Memtable heap size grows and many long GC pauses are triggered
--
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Assignee: Benedict
Priority: Critical
Fix For: 2.1.x
Attachments: cassandra.yaml, system.log.6.zip, system.log.7.zip,
system.log.8.zip, system.log.9.zip
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done
that and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Used memory on boxes where {{AllMemtabelesHeapSize}} grows, stays at the same
level -
https://www.dropbox.com/s/tes9abykixs86rf/Screenshot%202015-06-29%2019.37.52.png?dl=0.
Replication factor is set to 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-9680) Update CQL version
[ https://issues.apache.org/jira/browse/CASSANDRA-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-9680: - Assignee: Benjamin Lerer (was: Tyler Hobbs) Update CQL version -- Key: CASSANDRA-9680 URL: https://issues.apache.org/jira/browse/CASSANDRA-9680 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Benjamin Lerer Fix For: 2.2.0 rc2 I think we haven't upgraded the CQL spec version for 2.2 as far as I can tell. I say we should call it CQL 3.3. [~thobbs] Can you look at upgrading the version in the code and the doc? Listing the actual changes in the doc changelog would be awesome too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9640) Nodetool repair of very wide, large rows causes GC pressure and destabilization
[ https://issues.apache.org/jira/browse/CASSANDRA-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606183#comment-14606183 ] Jonathan Ellis commented on CASSANDRA-9640: --- I don't actually see GC pressure in the attached log zip. GCInspector says G1 old gen is stable at about 4GB which shouldn't be a problem unless you have a tiny heap. Nodetool repair of very wide, large rows causes GC pressure and destabilization --- Key: CASSANDRA-9640 URL: https://issues.apache.org/jira/browse/CASSANDRA-9640 Project: Cassandra Issue Type: Bug Environment: AWS, ~8GB heap Reporter: Constance Eustace Assignee: Yuki Morishita Priority: Minor Fix For: 2.1.x Attachments: syslog.zip We've noticed our nodes becoming unstable with large, unrecoverable Old Gen GCs until OOM. This appears to be around the time of repair, and the specific cause seems to be one of our report computation tables that involves possible very wide rows with 10GB of data in it. THis is an RF 3 table in a four-node cluster. We truncate this occasionally, and we also had disabled this computation report for a bit and noticed better node stabiliy. I wish I had more specifics. We are switching to an RF 1 table and do more proactive truncation of the table. When things calm down, we will attempt to replicate the issue and watch GC and other logs. Any suggestion for things to look for/enable tracing on would be welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9640) Nodetool repair of very wide, large rows causes GC pressure and destabilization
[ https://issues.apache.org/jira/browse/CASSANDRA-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606187#comment-14606187 ] Jonathan Ellis commented on CASSANDRA-9640: --- I do see lots of this in the log: bq. WARN [SharedPool-Worker-3] 2015-06-22 16:30:57,310 BatchStatement.java:243 - Batch of prepared statements for [publish_core.entity_asset, publish_core.relationbackref, publish_core.entity_product, publish_core.relation] is of size 5716, exceeding specified threshold of 5120 by 596. If you're using batches for bulk loading, don't. If you're not using batches for bulk loading, you may want to rethink your data model. Nodetool repair of very wide, large rows causes GC pressure and destabilization --- Key: CASSANDRA-9640 URL: https://issues.apache.org/jira/browse/CASSANDRA-9640 Project: Cassandra Issue Type: Bug Environment: AWS, ~8GB heap Reporter: Constance Eustace Assignee: Yuki Morishita Priority: Minor Fix For: 2.1.x Attachments: syslog.zip We've noticed our nodes becoming unstable with large, unrecoverable Old Gen GCs until OOM. This appears to be around the time of repair, and the specific cause seems to be one of our report computation tables that involves possible very wide rows with 10GB of data in it. THis is an RF 3 table in a four-node cluster. We truncate this occasionally, and we also had disabled this computation report for a bit and noticed better node stabiliy. I wish I had more specifics. We are switching to an RF 1 table and do more proactive truncation of the table. When things calm down, we will attempt to replicate the issue and watch GC and other logs. Any suggestion for things to look for/enable tracing on would be welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-9640) Nodetool repair of very wide, large rows causes GC pressure and destabilization
[ https://issues.apache.org/jira/browse/CASSANDRA-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-9640. --- Resolution: Not A Problem Assignee: (was: Yuki Morishita) Nodetool repair of very wide, large rows causes GC pressure and destabilization --- Key: CASSANDRA-9640 URL: https://issues.apache.org/jira/browse/CASSANDRA-9640 Project: Cassandra Issue Type: Bug Environment: AWS, ~8GB heap Reporter: Constance Eustace Priority: Minor Fix For: 2.1.x Attachments: syslog.zip We've noticed our nodes becoming unstable with large, unrecoverable Old Gen GCs until OOM. This appears to be around the time of repair, and the specific cause seems to be one of our report computation tables that involves possible very wide rows with 10GB of data in it. THis is an RF 3 table in a four-node cluster. We truncate this occasionally, and we also had disabled this computation report for a bit and noticed better node stabiliy. I wish I had more specifics. We are switching to an RF 1 table and do more proactive truncation of the table. When things calm down, we will attempt to replicate the issue and watch GC and other logs. Any suggestion for things to look for/enable tracing on would be welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9681) Memtable heap size grows and many long GC pauses are triggered
[
https://issues.apache.org/jira/browse/CASSANDRA-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-9681:
---
Assignee: Benedict
Memtable heap size grows and many long GC pauses are triggered
--
Key: CASSANDRA-9681
URL: https://issues.apache.org/jira/browse/CASSANDRA-9681
Project: Cassandra
Issue Type: Bug
Environment: C* 2.1.7, Debian Wheezy
Reporter: mlowicki
Assignee: Benedict
Priority: Critical
Fix For: 2.1.x
C* 2.1.7 cluster is behaving really bad after 1-2 days.
{{gauges.cassandra.jmx.org.apache.cassandra.metrics.ColumnFamily.AllMemtablesHeapSize.Value}}
jumps to 7 GB
(https://www.dropbox.com/s/vraggy292erkzd2/Screenshot%202015-06-29%2019.12.53.png?dl=0)
on 3/6 nodes in each data center and then there are many long GC pauses.
Cluster is using default heap size values ({{-Xms8192M -Xmx8192M -Xmn2048M}})
Before C* 2.1.5 memtables heap size was basically constant ~500MB
(https://www.dropbox.com/s/fjdywik5lojstvn/Screenshot%202015-06-29%2019.30.00.png?dl=0)
After restarting all nodes is behaves stable for 1-2days. Today I've done
that and long GC pauses are gone (~18:00
https://www.dropbox.com/s/7vo3ynz505rsfq3/Screenshot%202015-06-29%2019.28.37.png?dl=0).
The only pattern we've found so far is that long GC pauses are happening
basically at the same time on all nodes in the same data center - even on the
ones where memtables heap size is not growing.
Cliffs on the graphs are nodes restarts.
Used memory on boxes where {{AllMemtabelesHeapSize}} grows, stays at the same
level -
https://www.dropbox.com/s/tes9abykixs86rf/Screenshot%202015-06-29%2019.37.52.png?dl=0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
