[jira] [Updated] (CASSANDRA-8421) Cassandra 2.1.1 & Cassandra 2.1.2 UDT not returning value for LIST type as UDT
[
https://issues.apache.org/jira/browse/CASSANDRA-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
madheswaran updated CASSANDRA-8421:
---
Reproduced In: 2.1.2, 2.1.1 (was: 2.1.1, 2.1.2)
Summary: Cassandra 2.1.1 & Cassandra 2.1.2 UDT not returning value
for LIST type as UDT (was: Cassandra 2.1.1 UDT not returning value for LIST
type as UDT)
> Cassandra 2.1.1 & Cassandra 2.1.2 UDT not returning value for LIST type as UDT
> --
>
> Key: CASSANDRA-8421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8421
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Environment: single node cassandra
>Reporter: madheswaran
>Assignee: Sylvain Lebresne
> Fix For: 3.0, 2.1.3
>
> Attachments: 8421-unittest.txt, entity_data.csv
>
>
> I using List and its data type is UDT.
> UDT:
> {code}
> CREATE TYPE
> fieldmap (
> key text,
> value text
> );
> {code}
> TABLE:
> {code}
> CREATE TABLE entity (
> entity_id uuid PRIMARY KEY,
> begining int,
> domain text,
> domain_type text,
> entity_template_name text,
> field_values list,
> global_entity_type text,
> revision_time timeuuid,
> status_key int,
> status_name text,
> uuid timeuuid
> ) {code}
> INDEX:
> {code}
> CREATE INDEX entity_domain_idx_1 ON galaxy_dev.entity (domain);
> CREATE INDEX entity_field_values_idx_1 ON galaxy_dev.entity (field_values);
> CREATE INDEX entity_global_entity_type_idx_1 ON galaxy_dev.entity (gen_type );
> {code}
> QUERY
> {code}
> SELECT * FROM entity WHERE status_key < 3 and field_values contains {key:
> 'userName', value: 'Sprint5_22'} and gen_type = 'USER' and domain =
> 'S4_1017.abc.com' allow filtering;
> {code}
> The above query return value for some row and not for many rows but those
> rows and data's are exist.
> Observation:
> If I execute query with other than field_maps, then it returns value. I
> suspect the problem with LIST with UDT.
> I have single node cassadra DB. Please let me know why this strange behavior
> from cassandra.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8236) Delay "node up" and "node added" notifications until native protocol server is started
[
https://issues.apache.org/jira/browse/CASSANDRA-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240467#comment-14240467
]
Brandon Williams commented on CASSANDRA-8236:
-
Unfortunately, due to the new gossip state, 2.0 is out of the question.
> Delay "node up" and "node added" notifications until native protocol server
> is started
> --
>
> Key: CASSANDRA-8236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8236
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Brandon Williams
> Fix For: 3.0
>
> Attachments: 8236.txt
>
>
> As discussed in CASSANDRA-7510, there is still a gap between when a "node up"
> or "node added" notification may be sent to native protocol clients (in
> response to a gossip event) and when the native protocol server is ready to
> serve requests.
> Everything in between the call to {{StorageService.instance.initServer()}}
> and creation of the native server in {{CassandraDaemon.setup()}} contributes
> to this delay, but waiting for Gossip to settle introduces the biggest delay.
> We may need to introduce a "STARTING" gossip state for the period inbetween,
> which is why this is scheduled for 3.0. If there's a better option, though,
> it may make sense to put this in 2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8236) Delay "node up" and "node added" notifications until native protocol server is started
[
https://issues.apache.org/jira/browse/CASSANDRA-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240463#comment-14240463
]
Vishy Kasar commented on CASSANDRA-8236:
We have few clients hitting this. Is it possible to fix this in 2.0.12?
> Delay "node up" and "node added" notifications until native protocol server
> is started
> --
>
> Key: CASSANDRA-8236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8236
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Brandon Williams
> Fix For: 3.0
>
> Attachments: 8236.txt
>
>
> As discussed in CASSANDRA-7510, there is still a gap between when a "node up"
> or "node added" notification may be sent to native protocol clients (in
> response to a gossip event) and when the native protocol server is ready to
> serve requests.
> Everything in between the call to {{StorageService.instance.initServer()}}
> and creation of the native server in {{CassandraDaemon.setup()}} contributes
> to this delay, but waiting for Gossip to settle introduces the biggest delay.
> We may need to introduce a "STARTING" gossip state for the period inbetween,
> which is why this is scheduled for 3.0. If there's a better option, though,
> it may make sense to put this in 2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8452) Add missing systems to FBUtilities.isUnix, add FBUtilities.isWindows
[ https://issues.apache.org/jira/browse/CASSANDRA-8452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-8452: --- Fix Version/s: 2.1.3 > Add missing systems to FBUtilities.isUnix, add FBUtilities.isWindows > > > Key: CASSANDRA-8452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8452 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Minor > Fix For: 2.1.3 > > Attachments: CASSANDRA-8452.patch > > > The isUnix method leaves out a few unix systems, which, after the changes in > CASSANDRA-8136, causes some unexpected behavior during shutdown. It would > also be clearer if FBUtilities had an isWindows method for branching into > Windows specific logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8452) Add missing systems to FBUtilities.isUnix, add FBUtilities.isWindows
[ https://issues.apache.org/jira/browse/CASSANDRA-8452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-8452: --- Attachment: CASSANDRA-8452.patch > Add missing systems to FBUtilities.isUnix, add FBUtilities.isWindows > > > Key: CASSANDRA-8452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8452 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Minor > Fix For: 2.1.3 > > Attachments: CASSANDRA-8452.patch > > > The isUnix method leaves out a few unix systems, which, after the changes in > CASSANDRA-8136, causes some unexpected behavior during shutdown. It would > also be clearer if FBUtilities had an isWindows method for branching into > Windows specific logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8452) Add missing systems to FBUtilities.isUnix, add FBUtilities.isWindows
Blake Eggleston created CASSANDRA-8452: -- Summary: Add missing systems to FBUtilities.isUnix, add FBUtilities.isWindows Key: CASSANDRA-8452 URL: https://issues.apache.org/jira/browse/CASSANDRA-8452 Project: Cassandra Issue Type: Bug Reporter: Blake Eggleston Assignee: Blake Eggleston Priority: Minor The isUnix method leaves out a few unix systems, which, after the changes in CASSANDRA-8136, causes some unexpected behavior during shutdown. It would also be clearer if FBUtilities had an isWindows method for branching into Windows specific logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8451) NPE when writetime() or ttl() are nested inside function call
[
https://issues.apache.org/jira/browse/CASSANDRA-8451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-8451:
---
Attachment: 8451-2.0.txt
The problem was that we were using an {{instanceof WritetimeOrTTLSelector}}
check on selectors to see if timestamps or ttls needed to be collected. The
attached patch fixes that, and [I added a
dtest|https://github.com/thobbs/cassandra-dtest/tree/CASSANDRA-8451] as well.
> NPE when writetime() or ttl() are nested inside function call
> -
>
> Key: CASSANDRA-8451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8451
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Minor
> Fix For: 2.0.12, 2.1.3
>
> Attachments: 8451-2.0.txt
>
>
> When the {{writetime()}} or {{ttl()}} functions are nested inside another
> function, the query will result in a NullPointerException:
> {noformat}
> cqlsh> select bigintAsBlob(writetime(durable_writes)) from
> system.schema_keyspaces;
> message="java.lang.NullPointerException">
> {noformat}
> Here's the stacktrace:
> {noformat}
> ERROR 00:14:56 Unexpected exception during request
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.statements.Selection$WritetimeOrTTLSelector.compute(Selection.java:538)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.Selection$FunctionSelector.compute(Selection.java:462)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.Selection$SelectionWithProcessing.handleRow(Selection.java:434)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.Selection$ResultSetBuilder.newRow(Selection.java:331)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1243)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1177)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:274)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
> ~[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:471)
> [na:1.7.0_40]
> 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:724) [na:1.7.0_40]
> {noformat}
> Basically, it's failing to collect timestamps (or TTLs) when the function is
> wrapped. A similar query that additionally selects {{writetime()}} directly
> will succeed (because the timestamps will get collected):
> {noformat}
> cqlsh> select bigintAsBlob(writetime(durable_writes)),
> writetime(durable_writes) from system.schema_keyspaces ;
> bigintAsBlob(writetime(durable_writes)) | writetime(durable_writes)
> -+---
> 0x000509d1865c67f9 | 1418170390571001
> 0x | 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8451) NPE when writetime() or ttl() are nested inside function call
Tyler Hobbs created CASSANDRA-8451:
--
Summary: NPE when writetime() or ttl() are nested inside function
call
Key: CASSANDRA-8451
URL: https://issues.apache.org/jira/browse/CASSANDRA-8451
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 2.0.12, 2.1.3
When the {{writetime()}} or {{ttl()}} functions are nested inside another
function, the query will result in a NullPointerException:
{noformat}
cqlsh> select bigintAsBlob(writetime(durable_writes)) from
system.schema_keyspaces;
{noformat}
Here's the stacktrace:
{noformat}
ERROR 00:14:56 Unexpected exception during request
java.lang.NullPointerException: null
at
org.apache.cassandra.cql3.statements.Selection$WritetimeOrTTLSelector.compute(Selection.java:538)
~[main/:na]
at
org.apache.cassandra.cql3.statements.Selection$FunctionSelector.compute(Selection.java:462)
~[main/:na]
at
org.apache.cassandra.cql3.statements.Selection$SelectionWithProcessing.handleRow(Selection.java:434)
~[main/:na]
at
org.apache.cassandra.cql3.statements.Selection$ResultSetBuilder.newRow(Selection.java:331)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1243)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1177)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:274)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
~[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:471)
[na:1.7.0_40]
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:724) [na:1.7.0_40]
{noformat}
Basically, it's failing to collect timestamps (or TTLs) when the function is
wrapped. A similar query that additionally selects {{writetime()}} directly
will succeed (because the timestamps will get collected):
{noformat}
cqlsh> select bigintAsBlob(writetime(durable_writes)),
writetime(durable_writes) from system.schema_keyspaces ;
bigintAsBlob(writetime(durable_writes)) | writetime(durable_writes)
-+---
0x000509d1865c67f9 | 1418170390571001
0x | 0
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
[ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240305#comment-14240305 ] Robert Stupp commented on CASSANDRA-7438: - Yep - persisting the values would cause inconsistencies - either on it's own or by users deleting saved caches. > Serializing Row cache alternative (Fully off heap) > -- > > Key: CASSANDRA-7438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7438 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: Linux >Reporter: Vijay >Assignee: Vijay > Labels: performance > Fix For: 3.0 > > Attachments: 0001-CASSANDRA-7438.patch, tests.zip > > > Currently SerializingCache is partially off heap, keys are still stored in > JVM heap as BB, > * There is a higher GC costs for a reasonably big cache. > * Some users have used the row cache efficiently in production for better > results, but this requires careful tunning. > * Overhead in Memory for the cache entries are relatively high. > So the proposal for this ticket is to move the LRU cache logic completely off > heap and use JNI to interact with cache. We might want to ensure that the new > implementation match the existing API's (ICache), and the implementation > needs to have safe memory access, low overhead in memory and less memcpy's > (As much as possible). > We might also want to make this cache configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
[ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240235#comment-14240235 ] Ariel Weisberg commented on CASSANDRA-7438: --- bq. That's fair. I just saw some minutes ago that row-cache serialization "only" persists the keys and not the values - so the existing implementation in OHC would need to be changed / extended / whatever. I thought it persists the value, too. I was also confused by that. Persisting the values would break cache invalidation in a way that is hard to correct without integrating with the commit log. > Serializing Row cache alternative (Fully off heap) > -- > > Key: CASSANDRA-7438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7438 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: Linux >Reporter: Vijay >Assignee: Vijay > Labels: performance > Fix For: 3.0 > > Attachments: 0001-CASSANDRA-7438.patch, tests.zip > > > Currently SerializingCache is partially off heap, keys are still stored in > JVM heap as BB, > * There is a higher GC costs for a reasonably big cache. > * Some users have used the row cache efficiently in production for better > results, but this requires careful tunning. > * Overhead in Memory for the cache entries are relatively high. > So the proposal for this ticket is to move the LRU cache logic completely off > heap and use JNI to interact with cache. We might want to ensure that the new > implementation match the existing API's (ICache), and the implementation > needs to have safe memory access, low overhead in memory and less memcpy's > (As much as possible). > We might also want to make this cache configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8053) Support for user defined aggregate functions
[
https://issues.apache.org/jira/browse/CASSANDRA-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240204#comment-14240204
]
Tyler Hobbs commented on CASSANDRA-8053:
Review comments (I haven't tested anything yet :) ):
* AbstractFunction.usesFunction(): check for match uses endsWith() instead of
equals()
* Functions.addFunction(): when would get get a null function? That should
probably be handled elsewhere, if possible.
* UDAggregate:
** resolveScalar(): handle null names before calling resolveScalar() instead of
inside
** fromSchema(): when you use curlies on the "if" or "else", use them on the
other
* UDFunction:
** The o.a.c.db.* import got expanded
** Indentation of params on create() and createBrokenFunction() are off now
* CreateAggregateStatement:
** prepareKeyspace(): Change IRE message to: "Functions must be fully qualified
with a keyspace name if a keyspace is not set for the session"
** Keep whitespace in between '+' operators for string concatenation
** announceMigration(): checks for sfunc and finalfunc should include arg types
in the error messages
* CreateFunctionStatement:
** Error message for replacing aggregate with scalar is incorrect
* DropAggregateStatement:
** Class-level javadoc is incorrect
** Same note about IRE error message as CreateAggregate
** validate() javadoc can be deleted
* DefsTables:
** Indentation erroneously changed on Maps.difference() call
* AggregationTest:
** KS_FOO can be local to the single method that uses it
** testDropStatements(): test DROP IF EXISTS at the end, test ambiguous drop
with overloads
** Add test for INITCOND with bad type and null (which _should_ work)
** Add tests for bad sfunc arg types, bad return type
** Add test for bad finalfunc arg type, bad return type
** Add test for sfunc not existing, finalfunc not existing
** Add test for error during sfunc, finalfunc
> Support for user defined aggregate functions
>
>
> Key: CASSANDRA-8053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8053
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: cql, udf
> Fix For: 3.0
>
> Attachments: 8053v1.txt, 8053v2.txt
>
>
> CASSANDRA-4914 introduces aggregate functions.
> This ticket is about to decide how we can support "user defined aggregate
> functions". UD aggregate functions should be supported for all UDF flavors
> (class, java, jsr223).
> Things to consider:
> * Special implementations for each scripting language should be omitted
> * No exposure of internal APIs (e.g. {{AggregateFunction}} interface)
> * No need for users to deal with serializers / codecs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8450) Cassandra node announces availability before it is ready to accept CQL clients
[ https://issues.apache.org/jira/browse/CASSANDRA-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs resolved CASSANDRA-8450. Resolution: Duplicate Closing as a duplicate of CASSANDRA-8236 > Cassandra node announces availability before it is ready to accept CQL clients > -- > > Key: CASSANDRA-8450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8450 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Vishy Kasar > > We see cases where on a restart, the cassandra node announces the > availability to java driver clients before it is ready to accept CQL clients. > The java-driver gets an onUp message, attempts to create a connection to the > cassandra node which promptly rejects its connection. When there are large > number of clients, this error is seen by all clients. We should delay the > announcements until the node is ready to accept connections. > server log: > INFO [main] 2014-12-07 01:34:47,921 Server.java (line 156) Starting listening > for CQL clients on host/ip:9042... > client log: > com.datastax.driver.core.TransportException: [host1/ip1:9042] Cannot connect > at com.datastax.driver.core.Connection.(Connection.java:105) > at > com.datastax.driver.core.PooledConnection.(PooledConnection.java:35) > at com.datastax.driver.core.Connection$Factory.open(Connection.java:522) > at > com.datastax.driver.core.HostConnectionPool.(HostConnectionPool.java:86) > at > com.datastax.driver.core.SessionManager.replacePool(SessionManager.java:269) > at > com.datastax.driver.core.SessionManager.access$400(SessionManager.java:39) > at > com.datastax.driver.core.SessionManager$3.call(SessionManager.java:301) > at > com.datastax.driver.core.SessionManager$3.call(SessionManager.java:293) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: Connection refused: host1/ip1:9042 > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) > at > org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:150) > at > org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105) > at > org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) > at > org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42) > ... 3 more > 2014-12-07 01:34:44,011 [Cassandra Java Driver worker-1070] - onUp > address=ip1 host=host1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
[ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240193#comment-14240193 ] Robert Stupp commented on CASSANDRA-7438: - bq. Lot's of cool stuff Thx :) Unit testing: you are absolutely right. (Will go on with that next) bq. unit test that fuzzes against a parallel implementation at the same time using a different LRU map implementation Do you mean sth. like LinkedHashMap with removeEldestEntry() ? It's some effort to get a "nice" implementation for unit tests - but, yeah - makes sense. bq. duplicates reference counting code removed duplicated code bq. cleanup/eviction code go away ... remove entries until it [fits] much easier ; cleaner code ; implemented - but not completely sold on the new implementation yet (quick hack yet) bq. C* cache interface ... get compression and more efficient IO [later] That's fair. I just saw some minutes ago that row-cache serialization "only" persists the keys and not the values - so the existing implementation in OHC would need to be changed / extended / whatever. I thought it persists the value, too. > Serializing Row cache alternative (Fully off heap) > -- > > Key: CASSANDRA-7438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7438 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: Linux >Reporter: Vijay >Assignee: Vijay > Labels: performance > Fix For: 3.0 > > Attachments: 0001-CASSANDRA-7438.patch, tests.zip > > > Currently SerializingCache is partially off heap, keys are still stored in > JVM heap as BB, > * There is a higher GC costs for a reasonably big cache. > * Some users have used the row cache efficiently in production for better > results, but this requires careful tunning. > * Overhead in Memory for the cache entries are relatively high. > So the proposal for this ticket is to move the LRU cache logic completely off > heap and use JNI to interact with cache. We might want to ensure that the new > implementation match the existing API's (ICache), and the implementation > needs to have safe memory access, low overhead in memory and less memcpy's > (As much as possible). > We might also want to make this cache configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8450) Cassandra node announces availability before it is ready to accept CQL clients
Vishy Kasar created CASSANDRA-8450: -- Summary: Cassandra node announces availability before it is ready to accept CQL clients Key: CASSANDRA-8450 URL: https://issues.apache.org/jira/browse/CASSANDRA-8450 Project: Cassandra Issue Type: Bug Components: Core Reporter: Vishy Kasar We see cases where on a restart, the cassandra node announces the availability to java driver clients before it is ready to accept CQL clients. The java-driver gets an onUp message, attempts to create a connection to the cassandra node which promptly rejects its connection. When there are large number of clients, this error is seen by all clients. We should delay the announcements until the node is ready to accept connections. server log: INFO [main] 2014-12-07 01:34:47,921 Server.java (line 156) Starting listening for CQL clients on host/ip:9042... client log: com.datastax.driver.core.TransportException: [host1/ip1:9042] Cannot connect at com.datastax.driver.core.Connection.(Connection.java:105) at com.datastax.driver.core.PooledConnection.(PooledConnection.java:35) at com.datastax.driver.core.Connection$Factory.open(Connection.java:522) at com.datastax.driver.core.HostConnectionPool.(HostConnectionPool.java:86) at com.datastax.driver.core.SessionManager.replacePool(SessionManager.java:269) at com.datastax.driver.core.SessionManager.access$400(SessionManager.java:39) at com.datastax.driver.core.SessionManager$3.call(SessionManager.java:301) at com.datastax.driver.core.SessionManager$3.call(SessionManager.java:293) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.ConnectException: Connection refused: host1/ip1:9042 at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) at org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:150) at org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105) at org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79) at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) at org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42) ... 3 more 2014-12-07 01:34:44,011 [Cassandra Java Driver worker-1070] - onUp address=ip1 host=host1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240125#comment-14240125
]
Andrew Garrett commented on CASSANDRA-8430:
---
[~philipthompson] Sure, the schema in my original question is one such schema.
{code}
create table test(
pk text primary key,
foo bigint,
bar text
);
{code}
You'll have to forgive me for the confusing claim, but I wasn't able to
re-establish a case where just setting everything to null without involving
TTLs deleted a row. I may have been simply running into race conditions a few
days ago when I was testing this. However, I do have some examples of weird
behavior that I just reproduced now:
{code}
insert into test (pk, foo, bar) values ('abc', 2, 'whatever') using ttl 60;
update test set foo=null where pk='abc';
{code}
Now at first the row has 'abc', 2, 'whatever', then after the update it has
'abc', 0, 'whatever'. Then after 60 seconds the row gets deleted. Same thing if
you set bar to null, doesn't matter which. You can set both to null at the same
time and it will have the same effect. However, if you set foo to 0 instead of
null, the row doesn't get deleted, despite them having the same values.
Another strange case is when I do the following:
{code}
update test set bar='whatever' where pk='xyz';
update test set bar=null where pk='xyz';
{code}
After the first statement the row is present with 'xyz', 0, 'whatever'. After
the second statement the row gets deleted. I am also confused about the
difference between "insert" and "update" here. The following is valid and
inserts a row with all nulls:
{code}
insert into test (pk, foo, bar) values ('allnulls', null, null);
{code}
But this doesn't add a row:
{code}
update test set foo=null, bar=null where k='allnulls';
{code}
Yet I know that if I use "update" to set non-null values it will add a row. It
seems there's a difference between insert and update but I thought they were
the same thing behind the scenes.
I spent last Thursday and Friday digging through a lot of different cases and
I've lost track of all of the unexpected behaviors, and I may have gotten
confused, but hopefully you can shed some light on these cases.
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8449) Allow zero-copy reads again
[ https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8449: -- Labels: performance (was: ) > Allow zero-copy reads again > --- > > Key: CASSANDRA-8449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8449 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: performance > Fix For: 3.0 > > > We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads > accessing a ByteBuffer when the data was unmapped by compaction. Currently > this code path is only used for uncompressed reads. > The actual bytes are in fact copied to the client output buffers for both > netty and thrift before being sent over the wire, so the only issue really is > the time it takes to process the read internally. > This patch adds a slow network read test and changes the tidy() method to > actually delete a sstable once the readTimeout has elapsed giving plenty of > time to serialize the read. > Removing this copy causes significantly less GC on the read path and improves > the tail latencies: > http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688f&metric=gc_count&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=109.34&ymin=0&ymax=5.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8449) Allow zero-copy reads again
[ https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240121#comment-14240121 ] T Jake Luciani commented on CASSANDRA-8449: --- Patch is here https://github.com/tjake/cassandra/tree/mmap-uncompressed > Allow zero-copy reads again > --- > > Key: CASSANDRA-8449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8449 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: performance > Fix For: 3.0 > > > We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads > accessing a ByteBuffer when the data was unmapped by compaction. Currently > this code path is only used for uncompressed reads. > The actual bytes are in fact copied to the client output buffers for both > netty and thrift before being sent over the wire, so the only issue really is > the time it takes to process the read internally. > This patch adds a slow network read test and changes the tidy() method to > actually delete a sstable once the readTimeout has elapsed giving plenty of > time to serialize the read. > Removing this copy causes significantly less GC on the read path and improves > the tail latencies: > http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688f&metric=gc_count&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=109.34&ymin=0&ymax=5.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8449) Allow zero-copy reads again
T Jake Luciani created CASSANDRA-8449: - Summary: Allow zero-copy reads again Key: CASSANDRA-8449 URL: https://issues.apache.org/jira/browse/CASSANDRA-8449 Project: Cassandra Issue Type: Improvement Reporter: T Jake Luciani Priority: Minor Fix For: 3.0 We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads accessing a ByteBuffer when the data was unmapped by compaction. Currently this code path is only used for uncompressed reads. The actual bytes are in fact copied to the client output buffers for both netty and thrift before being sent over the wire, so the only issue really is the time it takes to process the read internally. This patch adds a slow network read test and changes the tidy() method to actually delete a sstable once the readTimeout has elapsed giving plenty of time to serialize the read. Removing this copy causes significantly less GC on the read path and improves the tail latencies: http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688f&metric=gc_count&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=109.34&ymin=0&ymax=5.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8448) "Comparison method violates its general contract" in AbstractEndpointSnitch
[
https://issues.apache.org/jira/browse/CASSANDRA-8448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.B. Langston updated CASSANDRA-8448:
-
Description:
Seen in both 1.2 and 2.0. The error is occurring here:
https://github.com/apache/cassandra/blob/cassandra-2.0/src/java/org/apache/cassandra/locator/AbstractEndpointSnitch.java#L49
{code}
ERROR [Thrift:9] 2014-12-04 20:12:28,732 CustomTThreadPoolServer.java (line
219) Error occurred during processing of message.
com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.IllegalArgumentException: Comparison method violates its general
contract!
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
at
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
at
org.apache.cassandra.service.ClientState.authorize(ClientState.java:352)
at
org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:224)
at
org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:218)
at
org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:202)
at
org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:822)
at
org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:954)
at com.datastax.bdp.server.DseServer.batch_mutate(DseServer.java:576)
at
org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3922)
at
org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3906)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: Comparison method violates its
general contract!
at java.util.TimSort.mergeHi(TimSort.java:868)
at java.util.TimSort.mergeAt(TimSort.java:485)
at java.util.TimSort.mergeCollapse(TimSort.java:410)
at java.util.TimSort.sort(TimSort.java:214)
at java.util.TimSort.sort(TimSort.java:173)
at java.util.Arrays.sort(Arrays.java:659)
at java.util.Collections.sort(Collections.java:217)
at
org.apache.cassandra.locator.AbstractEndpointSnitch.sortByProximity(AbstractEndpointSnitch.java:49)
at
org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximityWithScore(DynamicEndpointSnitch.java:157)
at
org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximityWithBadness(DynamicEndpointSnitch.java:186)
at
org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximity(DynamicEndpointSnitch.java:151)
at
org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1408)
at
org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1402)
at
org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:148)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1223)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1165)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:255)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:225)
at org.apache.cassandra.auth.Auth.selectUser(Auth.java:243)
at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:84)
at
org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50)
at
org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:69)
at org.apache.cassandra.service.ClientState$1.load(ClientState.java:338)
at org.apache.cassandra.service.ClientState$1.load(ClientState.java:335)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
... 18 more
{code}
Workaround: Setting -Djava.util.Arrays.useLegacyMergeSort=true causes the
error to go away.
was:
Seen in both 1.2 and 2.0. The err
[jira] [Created] (CASSANDRA-8448) "Comparison method violates its general contract" in AbstractEndpointSnitch
J.B. Langston created CASSANDRA-8448: Summary: "Comparison method violates its general contract" in AbstractEndpointSnitch Key: CASSANDRA-8448 URL: https://issues.apache.org/jira/browse/CASSANDRA-8448 Project: Cassandra Issue Type: Bug Reporter: J.B. Langston Seen in both 1.2 and 2.0. The error is occurring here: https://github.com/apache/cassandra/blob/cassandra-2.0/src/java/org/apache/cassandra/locator/AbstractEndpointSnitch.java#L49 ERROR [Thrift:9] 2014-12-04 20:12:28,732 CustomTThreadPoolServer.java (line 219) Error occurred during processing of message. com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalArgumentException: Comparison method violates its general contract! at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) at com.google.common.cache.LocalCache.get(LocalCache.java:3932) at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936) at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806) at org.apache.cassandra.service.ClientState.authorize(ClientState.java:352) at org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:224) at org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:218) at org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:202) at org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:822) at org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:954) at com.datastax.bdp.server.DseServer.batch_mutate(DseServer.java:576) at org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3922) at org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3906) at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: Comparison method violates its general contract! at java.util.TimSort.mergeHi(TimSort.java:868) at java.util.TimSort.mergeAt(TimSort.java:485) at java.util.TimSort.mergeCollapse(TimSort.java:410) at java.util.TimSort.sort(TimSort.java:214) at java.util.TimSort.sort(TimSort.java:173) at java.util.Arrays.sort(Arrays.java:659) at java.util.Collections.sort(Collections.java:217) at org.apache.cassandra.locator.AbstractEndpointSnitch.sortByProximity(AbstractEndpointSnitch.java:49) at org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximityWithScore(DynamicEndpointSnitch.java:157) at org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximityWithBadness(DynamicEndpointSnitch.java:186) at org.apache.cassandra.locator.DynamicEndpointSnitch.sortByProximity(DynamicEndpointSnitch.java:151) at org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1408) at org.apache.cassandra.service.StorageProxy.getLiveSortedEndpoints(StorageProxy.java:1402) at org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:148) at org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1223) at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1165) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:255) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:225) at org.apache.cassandra.auth.Auth.selectUser(Auth.java:243) at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:84) at org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50) at org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:69) at org.apache.cassandra.service.ClientState$1.load(ClientState.java:338) at org.apache.cassandra.service.ClientState$1.load(ClientState.java:335) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193) ..
[jira] [Updated] (CASSANDRA-8447) Nodes stuck in CMS GC cycle with very little traffic when compaction is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jonathan lacefield updated CASSANDRA-8447: -- Description: Behavior - If autocompaction is enabled, nodes will become unresponsive due to a full Old Gen heap which is not cleared during CMS GC. Test methodology - disabled autocompaction on 3 nodes, left autocompaction enabled on 1 node. Executed different Cassandra stress loads, using write only operations. Monitored visualvm and jconsole for heap pressure. Captured iostat and dstat for most tests. Captured heap dump from 50 thread load. Hints were disabled for testing on all nodes to alleviate GC noise due to hints backing up. Data load test through Cassandra stress - /usr/bin/cassandra-stress write n=19 -rate threads= -schema replication\(factor=3\) keyspace="Keyspace1" -node Data load thread count and results: * 1 thread - Still running but looks like the node can sustain this load (approx 500 writes per second per node) * 5 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 2k writes per second per node) * 10 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range * 50 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 10k writes per second per node) * 100 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 20k writes per second per node) * 200 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 25k writes per second per node) Note - the observed behavior was the same for all tests except for the single threaded test. The single threaded test does not appear to show this behavior. Tested different GC and Linux OS settings with a focus on the 50 and 200 thread loads. JVM settings tested: # default, out of the box, env-sh settings # 10 G Max | 1 G New - default env-sh settings # 10 G Max | 1 G New - default env-sh settings #* JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=50" # 20 G Max | 10 G New JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8" JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=8" JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75" JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS="$JVM_OPTS -XX:+UseTLAB" JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS="$JVM_OPTS -XX:CMSMaxAbortablePrecleanTime=6" JVM_OPTS="$JVM_OPTS -XX:CMSWaitDuration=3" JVM_OPTS="$JVM_OPTS -XX:ParallelGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:ConcGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS="$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS="$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" JVM_OPTS="$JVM_OPTS -XX:ParGCCardsPerStrideChunk=32768" JVM_OPTS="$JVM_OPTS -XX:-UseBiasedLocking" # 20 G Max | 1 G New JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8" JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=8" JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75" JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS="$JVM_OPTS -XX:+UseTLAB" JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS="$JVM_OPTS -XX:CMSMaxAbortablePrecleanTime=6" JVM_OPTS="$JVM_OPTS -XX:CMSWaitDuration=3" JVM_OPTS="$JVM_OPTS -XX:ParallelGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:ConcGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS="$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS="$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" JVM_OPTS="$JVM_OPTS -XX:ParGCCardsPerStrideChunk=32768" JVM_OPTS="$JVM_OPTS -XX:-UseBiasedLocking" Linux OS settings tested: # Disabled Transparent Huge Pages echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # Enabled Huge Pages echo 215 > /proc/sys/kernel/shmmax (over 20GB for heap) echo 1536 > /proc/sys/vm/nr_hugepages (20GB/2MB page size) # Disabled NUMA numa-off in /etc/grub.confdatastax # Verified all settings documented here were implemented http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installRecommendSettings.html Attachments: # .yaml # fio output - results.tar.gz # 50 thread heap dump - will update new heap dump soon # 100 thread - visual vm anonymous screenshot - visualvm_screenshot # dstat screen shot of with compaction - Node_with_compaction.png # dstat screen shot of without compaction -- Node_without_compaction.png # gcinspector m
[jira] [Updated] (CASSANDRA-8447) Nodes stuck in CMS GC cycle with very little traffic when compaction is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jonathan lacefield updated CASSANDRA-8447: -- Description: Behavior - If autocompaction is enabled, nodes will become unresponsive due to a full Old Gen heap which is not cleared during CMS GC. Test methodology - disabled autocompaction on 3 nodes, left autocompaction enabled on 1 node. Executed different Cassandra stress loads, using write only operations. Monitored visualvm and jconsole for heap pressure. Captured iostat and dstat for most tests. Captured heap dump from 50 thread load. Hints were disabled for testing on all nodes to alleviate GC noise due to hints backing up. Data load test through Cassandra stress - /usr/bin/cassandra-stress write n=19 -rate threads= -schema replication\(factor=3\) keyspace="Keyspace1" -node Data load thread count and results: * 1 thread - Still running but looks like the node can sustain this load (approx 500 writes per second per node) * 5 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 2k writes per second per node) * 10 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range * 50 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 10k writes per second per node) * 100 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range * 200 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 20k writes per second per node) Note - the observed behavior was the same for all tests except for the single threaded test. The single threaded test does not appear to show this behavior. Tested different GC and Linux OS settings with a focus on the 50 and 200 thread loads. JVM settings tested: # default, out of the box, env-sh settings # 10 G Max | 1 G New - default env-sh settings # 10 G Max | 1 G New - default env-sh settings #* JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=50" # 20 G Max | 10 G New JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8" JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=8" JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75" JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS="$JVM_OPTS -XX:+UseTLAB" JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS="$JVM_OPTS -XX:CMSMaxAbortablePrecleanTime=6" JVM_OPTS="$JVM_OPTS -XX:CMSWaitDuration=3" JVM_OPTS="$JVM_OPTS -XX:ParallelGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:ConcGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS="$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS="$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" JVM_OPTS="$JVM_OPTS -XX:ParGCCardsPerStrideChunk=32768" JVM_OPTS="$JVM_OPTS -XX:-UseBiasedLocking" # 20 G Max | 1 G New JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8" JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=8" JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75" JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS="$JVM_OPTS -XX:+UseTLAB" JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS="$JVM_OPTS -XX:CMSMaxAbortablePrecleanTime=6" JVM_OPTS="$JVM_OPTS -XX:CMSWaitDuration=3" JVM_OPTS="$JVM_OPTS -XX:ParallelGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:ConcGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS="$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS="$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" JVM_OPTS="$JVM_OPTS -XX:ParGCCardsPerStrideChunk=32768" JVM_OPTS="$JVM_OPTS -XX:-UseBiasedLocking" Linux OS settings tested: # Disabled Transparent Huge Pages echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # Enabled Huge Pages echo 215 > /proc/sys/kernel/shmmax (over 20GB for heap) echo 1536 > /proc/sys/vm/nr_hugepages (20GB/2MB page size) # Disabled NUMA numa-off in /etc/grub.confdatastax # Verified all settings documented here were implemented http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installRecommendSettings.html Attachments: # .yaml # fio output - results.tar.gz # 50 thread heap dump - will update new heap dump soon # 100 thread - visual vm anonymous screenshot - visualvm_screenshot # dstat screen shot of with compaction - Node_with_compaction.png # dstat screen shot of without compaction -- Node_without_compaction.png # gcinspector messages from system.log # gc.log output -
[jira] [Commented] (CASSANDRA-8446) Lost writes when using lightweight transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239994#comment-14239994 ] Sylvain Lebresne commented on CASSANDRA-8446: - I'm afraid nothing in this description indicates a bug. Ligthweight transactions can throw write timeouts and they will under heavy contention. And a greater replica factor does make it somewhat more likely. It's something to be aware of and that your application should defend against by handling those timeouts (which is not really specific to lightweigth transactions). This is why lightweigth transactions are not recommended if you have lots of contention: they just don't perform very well in this case as of the current implementation. > Lost writes when using lightweight transactions > --- > > Key: CASSANDRA-8446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8446 > Project: Cassandra > Issue Type: Bug > Components: API, Core > Environment: Cassandra 2.1.2 on Java(TM) SE Runtime Environment > (build 1.7.0_65-b17) >Reporter: Jochen Zeischka > Fix For: 2.1.3 > > > There's a serious problem when using lightweight transactions. Whenever th > cluster gets any load, write timeout exceptions start to occur and the client > has no way to know whether the write actually succeeded or not. > I a simple test (https://gist.github.com/anonymous/4c83f2962b57fce4c3df) this > results in large percentages of lost writes (0 - 50%, depending on the load). > The problem was described in > https://stackoverflow.com/questions/27313360/how-can-we-avoid-losing-writes-when-using-lightweight-transactions-cas-in-cass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239978#comment-14239978
]
Philip Thompson commented on CASSANDRA-8430:
[~angarrett], can you post the schema of a table that deletes a row when
setting the non-partition keys to null?
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8194) Reading from Auth table should not be in the request path
[ https://issues.apache.org/jira/browse/CASSANDRA-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishy Kasar updated CASSANDRA-8194: --- Attachment: CacheTest2.java Jeremiah, An attempt will be made to update at each refreshAfterWrite interval as long as there are active requests. Even if some of those refresh attempts fail/time-out, there will be others attempted as long as there are active requests. Some of those attempts should succeed and refresh the cache. If there are no active requests, then we do not care if the entry in cache is stale or not. I have attached a simple CacheTest2.java that illustrates this. Let me know if this is still a concern. > Reading from Auth table should not be in the request path > - > > Key: CASSANDRA-8194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8194 > Project: Cassandra > Issue Type: Improvement >Reporter: Vishy Kasar >Priority: Minor > Fix For: 2.0.12, 3.0 > > Attachments: 8194-V2.patch, 8194.patch, CacheTest2.java > > > We use PasswordAuthenticator and PasswordAuthorizer. The system_auth has a RF > of 10 per DC over 2 DCs. The permissions_validity_in_ms is 5 minutes. > We still have few thousand requests failing each day with the trace below. > The reason for this is read cache request realizing that cached entry has > expired and doing a blocking request to refresh cache. > We should have cache refreshed periodically only in the back ground. The user > request should simply look at the cache and not try to refresh it. > com.google.common.util.concurrent.UncheckedExecutionException: > java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2258) > at com.google.common.cache.LocalCache.get(LocalCache.java:3990) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878) > at > org.apache.cassandra.service.ClientState.authorize(ClientState.java:292) > at > org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:172) > at > org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:165) > at > org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:149) > at > org.apache.cassandra.cql3.statements.ModificationStatement.checkAccess(ModificationStatement.java:75) > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:102) > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:113) > at > org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1735) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4162) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4150) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:206) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at org.apache.cassandra.auth.Auth.selectUser(Auth.java:256) > at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:84) > at > org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50) > at > org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:68) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:278) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:275) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589) > at > com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252) > ... 19 more > Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation > timed out - received only 0 responses. > at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:105)
[jira] [Commented] (CASSANDRA-8261) Clean up schema metadata classes
[
https://issues.apache.org/jira/browse/CASSANDRA-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239977#comment-14239977
]
Tyler Hobbs commented on CASSANDRA-8261:
Overall it seems pretty reasonable so far. My review comments are mostly about
renaming things for clarity, because SchemaTables currently has a lot of
similarly-named things that are a bit confusing at first. Some terms (like
"serialize(d)") seem to be used to mean different things.
SchemaTables:
* {{serializedTables/UserTypes/UserFunctions()}}: need a short java doc, maybe
rename to {{getTableRowsForKeyspace()}}, etc
* {{readSchemaFromDisk()}}: maybe rename to {{readSchemaFromSytemTables()}}
* {{addToSchemaMutation()}}: I suggest renaming the overloaded methods that
apply to tables, columns, and triggers to: {{addTableToSchemaMutation()}},
{{addColumnToSchemaMutation()}}, and {{addTriggerToSchemaMutation()}}
* {{addToDropFromSchemaMutation()}}: rename overloaded methods to:
{{addTableDropToSchemaMutation()}}, {{addColumnDropToSchemaMutation()}}, etc.
The current name is really confusing :)
* {{toSchemaMutation()}}, {{toUpdateSchemaMutation()}},
{{toDropSchemaMutation()}}: maybe rename to {{makeDropSchemaMutation()}}, etc
* {{getSchema()}}: could use a javadoc
* {{serializedSchema()}}: rename to {{getSchemaTableRows()}}, improve javadoc
* {{serializeSchema()}}: rename to {{schemaTablesToMutation()}}, add javadoc
* {{serializeSchema(map, table)}}: rename to {{addSchemaTableToMutation()}},
add javadoc
SystemKeyspaces:
* There's a TODO about making BuiltIndexesTable private, and a related FIXME in
{{SchemaTables.toDropFromSchemaMutation()}}
> Clean up schema metadata classes
>
>
> Key: CASSANDRA-8261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8261
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 8261-isolate-hadcoded-system-tables.txt,
> 8261-isolate-serialization-code.txt, 8261-isolate-thrift-code.txt
>
>
> While working on CASSANDRA-6717, I've made some general cleanup changes to
> schema metadata classes - distracted from the core purpose. Also, being
> distracted from it by other things, every time I come back to it gives me a
> bit of a rebase hell.
> Thus I'm isolating those changes into a separate issue here, hoping to commit
> them one by one, before I go back and finalize CASSANDRA-6717.
> The changes include:
> - moving all the toThrift/fromThrift conversion code to ThriftConversion,
> where it belongs
> - moving the complied system CFMetaData objects away from CFMetaData (to
> SystemKeyspace and TracesKeyspace)
> - isolating legacy toSchema/fromSchema code into a separate class
> (LegacySchemaTables - former DefsTables)
> - refactoring CFMetaData/KSMetaData fields to match CQL CREATE TABLE syntax,
> and encapsulating more things in
> CompactionOptions/CompressionOptions/ReplicationOptions classes
> - moving the definition classes to the new 'schema' package
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[2/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d69728f8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d69728f8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d69728f8 Branch: refs/heads/trunk Commit: d69728f8a5297e3e91415ee35689e54120797977 Parents: 7fa0341 77df557 Author: Sylvain Lebresne Authored: Tue Dec 9 21:10:35 2014 +0100 Committer: Sylvain Lebresne Committed: Tue Dec 9 21:10:35 2014 +0100 -- CHANGES.txt | 1 + .../cassandra/exceptions/UnavailableException.java| 7 ++- .../org/apache/cassandra/service/StorageProxy.java| 14 +- 3 files changed, 20 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d69728f8/CHANGES.txt -- diff --cc CHANGES.txt index 28dd6b4,3c651ff..3545afc --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,23 -1,5 +1,24 @@@ -2.0.12: +2.1.3 + * Reduce maxHintsInProgress (CASSANDRA-8415) + * BTree updates may call provided update function twice (CASSANDRA-8018) + * Release sstable references after anticompaction (CASSANDRA-8386) + * Handle abort() in SSTableRewriter properly (CASSANDRA-8320) + * Fix high size calculations for prepared statements (CASSANDRA-8231) + * Centralize shared executors (CASSANDRA-8055) + * Fix filtering for CONTAINS (KEY) relations on frozen collection + clustering columns when the query is restricted to a single + partition (CASSANDRA-8203) + * Do more aggressive entire-sstable TTL expiry checks (CASSANDRA-8243) + * Add more log info if readMeter is null (CASSANDRA-8238) + * add check of the system wall clock time at startup (CASSANDRA-8305) + * Support for frozen collections (CASSANDRA-7859) + * Fix overflow on histogram computation (CASSANDRA-8028) + * Have paxos reuse the timestamp generation of normal queries (CASSANDRA-7801) + * Fix incremental repair not remove parent session on remote (CASSANDRA-8291) + * Improve JBOD disk utilization (CASSANDRA-7386) + * Log failed host when preparing incremental repair (CASSANDRA-8228) +Merged from 2.0: + * Refuse Paxos operation with more than one pending endpoint (CASSANDRA-8346) * Throw correct exception when trying to bind a keyspace or table name (CASSANDRA-6952) * Make HHOM.compact synchronized (CASSANDRA-8416) http://git-wip-us.apache.org/repos/asf/cassandra/blob/d69728f8/src/java/org/apache/cassandra/service/StorageProxy.java --
[3/3] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2240455f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2240455f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2240455f Branch: refs/heads/trunk Commit: 2240455f0e963e410c274dfc43f725111c115d5a Parents: 178d7b6 d69728f Author: Sylvain Lebresne Authored: Tue Dec 9 21:11:19 2014 +0100 Committer: Sylvain Lebresne Committed: Tue Dec 9 21:11:19 2014 +0100 -- CHANGES.txt | 1 + .../cassandra/exceptions/UnavailableException.java| 7 ++- .../org/apache/cassandra/service/StorageProxy.java| 14 +- 3 files changed, 20 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2240455f/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2240455f/src/java/org/apache/cassandra/service/StorageProxy.java --
[1/3] cassandra git commit: Refuse Paxos operations with more than one pending endpoints
Repository: cassandra
Updated Branches:
refs/heads/trunk 178d7b6f8 -> 2240455f0
Refuse Paxos operations with more than one pending endpoints
patch by slebresne; reviewed by kohlisankalp for CASSANDRA-8346
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/77df5578
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/77df5578
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/77df5578
Branch: refs/heads/trunk
Commit: 77df5578a0c80f9e8b5de914fa75d1bda023a4f5
Parents: 71e1219
Author: Sylvain Lebresne
Authored: Tue Dec 9 21:08:48 2014 +0100
Committer: Sylvain Lebresne
Committed: Tue Dec 9 21:08:48 2014 +0100
--
CHANGES.txt | 1 +
.../cassandra/exceptions/UnavailableException.java| 7 ++-
.../org/apache/cassandra/service/StorageProxy.java| 14 +-
3 files changed, 20 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7c89e60..3c651ff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Refuse Paxos operation with more than one pending endpoint (CASSANDRA-8346)
* Throw correct exception when trying to bind a keyspace or table
name (CASSANDRA-6952)
* Make HHOM.compact synchronized (CASSANDRA-8416)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/src/java/org/apache/cassandra/exceptions/UnavailableException.java
--
diff --git a/src/java/org/apache/cassandra/exceptions/UnavailableException.java
b/src/java/org/apache/cassandra/exceptions/UnavailableException.java
index e557550..baee0b2 100644
--- a/src/java/org/apache/cassandra/exceptions/UnavailableException.java
+++ b/src/java/org/apache/cassandra/exceptions/UnavailableException.java
@@ -27,7 +27,12 @@ public class UnavailableException extends
RequestExecutionException
public UnavailableException(ConsistencyLevel consistency, int required,
int alive)
{
-super(ExceptionCode.UNAVAILABLE, "Cannot achieve consistency level " +
consistency);
+this("Cannot achieve consistency level " + consistency, consistency,
required, alive);
+}
+
+public UnavailableException(String msg, ConsistencyLevel consistency, int
required, int alive)
+{
+super(ExceptionCode.UNAVAILABLE, msg);
this.consistency = consistency;
this.required = required;
this.alive = alive;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d8b6619..f877aee 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -304,6 +304,7 @@ public class StorageProxy implements StorageProxyMBean
Token tk = StorageService.getPartitioner().getToken(key);
List naturalEndpoints =
StorageService.instance.getNaturalEndpoints(keyspaceName, tk);
Collection pendingEndpoints =
StorageService.instance.getTokenMetadata().pendingEndpointsFor(tk,
keyspaceName);
+
if (consistencyForPaxos == ConsistencyLevel.LOCAL_SERIAL)
{
// Restrict naturalEndpoints and pendingEndpoints to node in the
local DC only
@@ -312,10 +313,21 @@ public class StorageProxy implements StorageProxyMBean
naturalEndpoints =
ImmutableList.copyOf(Iterables.filter(naturalEndpoints, isLocalDc));
pendingEndpoints =
ImmutableList.copyOf(Iterables.filter(pendingEndpoints, isLocalDc));
}
-int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
+int participants = pendingEndpoints.size() + naturalEndpoints.size();
+int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
List liveEndpoints =
ImmutableList.copyOf(Iterables.filter(Iterables.concat(naturalEndpoints,
pendingEndpoints), IAsyncCallback.isAlive));
if (liveEndpoints.size() < requiredParticipants)
throw new UnavailableException(consistencyForPaxos,
requiredParticipants, liveEndpoints.size());
+
+// We cannot allow CAS operations with 2 or more pending endpoints,
see #8346.
+// Note that we fake an impossible number of required nodes in the
unavailable exception
+// to nail home the point that it's an impossible operation no matter
how many nodes are live.
+if (pen
[1/2] cassandra git commit: Refuse Paxos operations with more than one pending endpoints
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 7fa034136 -> d69728f8a
Refuse Paxos operations with more than one pending endpoints
patch by slebresne; reviewed by kohlisankalp for CASSANDRA-8346
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/77df5578
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/77df5578
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/77df5578
Branch: refs/heads/cassandra-2.1
Commit: 77df5578a0c80f9e8b5de914fa75d1bda023a4f5
Parents: 71e1219
Author: Sylvain Lebresne
Authored: Tue Dec 9 21:08:48 2014 +0100
Committer: Sylvain Lebresne
Committed: Tue Dec 9 21:08:48 2014 +0100
--
CHANGES.txt | 1 +
.../cassandra/exceptions/UnavailableException.java| 7 ++-
.../org/apache/cassandra/service/StorageProxy.java| 14 +-
3 files changed, 20 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7c89e60..3c651ff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Refuse Paxos operation with more than one pending endpoint (CASSANDRA-8346)
* Throw correct exception when trying to bind a keyspace or table
name (CASSANDRA-6952)
* Make HHOM.compact synchronized (CASSANDRA-8416)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/src/java/org/apache/cassandra/exceptions/UnavailableException.java
--
diff --git a/src/java/org/apache/cassandra/exceptions/UnavailableException.java
b/src/java/org/apache/cassandra/exceptions/UnavailableException.java
index e557550..baee0b2 100644
--- a/src/java/org/apache/cassandra/exceptions/UnavailableException.java
+++ b/src/java/org/apache/cassandra/exceptions/UnavailableException.java
@@ -27,7 +27,12 @@ public class UnavailableException extends
RequestExecutionException
public UnavailableException(ConsistencyLevel consistency, int required,
int alive)
{
-super(ExceptionCode.UNAVAILABLE, "Cannot achieve consistency level " +
consistency);
+this("Cannot achieve consistency level " + consistency, consistency,
required, alive);
+}
+
+public UnavailableException(String msg, ConsistencyLevel consistency, int
required, int alive)
+{
+super(ExceptionCode.UNAVAILABLE, msg);
this.consistency = consistency;
this.required = required;
this.alive = alive;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d8b6619..f877aee 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -304,6 +304,7 @@ public class StorageProxy implements StorageProxyMBean
Token tk = StorageService.getPartitioner().getToken(key);
List naturalEndpoints =
StorageService.instance.getNaturalEndpoints(keyspaceName, tk);
Collection pendingEndpoints =
StorageService.instance.getTokenMetadata().pendingEndpointsFor(tk,
keyspaceName);
+
if (consistencyForPaxos == ConsistencyLevel.LOCAL_SERIAL)
{
// Restrict naturalEndpoints and pendingEndpoints to node in the
local DC only
@@ -312,10 +313,21 @@ public class StorageProxy implements StorageProxyMBean
naturalEndpoints =
ImmutableList.copyOf(Iterables.filter(naturalEndpoints, isLocalDc));
pendingEndpoints =
ImmutableList.copyOf(Iterables.filter(pendingEndpoints, isLocalDc));
}
-int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
+int participants = pendingEndpoints.size() + naturalEndpoints.size();
+int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
List liveEndpoints =
ImmutableList.copyOf(Iterables.filter(Iterables.concat(naturalEndpoints,
pendingEndpoints), IAsyncCallback.isAlive));
if (liveEndpoints.size() < requiredParticipants)
throw new UnavailableException(consistencyForPaxos,
requiredParticipants, liveEndpoints.size());
+
+// We cannot allow CAS operations with 2 or more pending endpoints,
see #8346.
+// Note that we fake an impossible number of required nodes in the
unavailable exception
+// to nail home the point that it's an impossible operation no matter
how many nodes are live.
[2/2] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d69728f8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d69728f8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d69728f8 Branch: refs/heads/cassandra-2.1 Commit: d69728f8a5297e3e91415ee35689e54120797977 Parents: 7fa0341 77df557 Author: Sylvain Lebresne Authored: Tue Dec 9 21:10:35 2014 +0100 Committer: Sylvain Lebresne Committed: Tue Dec 9 21:10:35 2014 +0100 -- CHANGES.txt | 1 + .../cassandra/exceptions/UnavailableException.java| 7 ++- .../org/apache/cassandra/service/StorageProxy.java| 14 +- 3 files changed, 20 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d69728f8/CHANGES.txt -- diff --cc CHANGES.txt index 28dd6b4,3c651ff..3545afc --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,23 -1,5 +1,24 @@@ -2.0.12: +2.1.3 + * Reduce maxHintsInProgress (CASSANDRA-8415) + * BTree updates may call provided update function twice (CASSANDRA-8018) + * Release sstable references after anticompaction (CASSANDRA-8386) + * Handle abort() in SSTableRewriter properly (CASSANDRA-8320) + * Fix high size calculations for prepared statements (CASSANDRA-8231) + * Centralize shared executors (CASSANDRA-8055) + * Fix filtering for CONTAINS (KEY) relations on frozen collection + clustering columns when the query is restricted to a single + partition (CASSANDRA-8203) + * Do more aggressive entire-sstable TTL expiry checks (CASSANDRA-8243) + * Add more log info if readMeter is null (CASSANDRA-8238) + * add check of the system wall clock time at startup (CASSANDRA-8305) + * Support for frozen collections (CASSANDRA-7859) + * Fix overflow on histogram computation (CASSANDRA-8028) + * Have paxos reuse the timestamp generation of normal queries (CASSANDRA-7801) + * Fix incremental repair not remove parent session on remote (CASSANDRA-8291) + * Improve JBOD disk utilization (CASSANDRA-7386) + * Log failed host when preparing incremental repair (CASSANDRA-8228) +Merged from 2.0: + * Refuse Paxos operation with more than one pending endpoint (CASSANDRA-8346) * Throw correct exception when trying to bind a keyspace or table name (CASSANDRA-6952) * Make HHOM.compact synchronized (CASSANDRA-8416) http://git-wip-us.apache.org/repos/asf/cassandra/blob/d69728f8/src/java/org/apache/cassandra/service/StorageProxy.java --
cassandra git commit: Refuse Paxos operations with more than one pending endpoints
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 71e1219de -> 77df5578a
Refuse Paxos operations with more than one pending endpoints
patch by slebresne; reviewed by kohlisankalp for CASSANDRA-8346
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/77df5578
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/77df5578
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/77df5578
Branch: refs/heads/cassandra-2.0
Commit: 77df5578a0c80f9e8b5de914fa75d1bda023a4f5
Parents: 71e1219
Author: Sylvain Lebresne
Authored: Tue Dec 9 21:08:48 2014 +0100
Committer: Sylvain Lebresne
Committed: Tue Dec 9 21:08:48 2014 +0100
--
CHANGES.txt | 1 +
.../cassandra/exceptions/UnavailableException.java| 7 ++-
.../org/apache/cassandra/service/StorageProxy.java| 14 +-
3 files changed, 20 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7c89e60..3c651ff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Refuse Paxos operation with more than one pending endpoint (CASSANDRA-8346)
* Throw correct exception when trying to bind a keyspace or table
name (CASSANDRA-6952)
* Make HHOM.compact synchronized (CASSANDRA-8416)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/src/java/org/apache/cassandra/exceptions/UnavailableException.java
--
diff --git a/src/java/org/apache/cassandra/exceptions/UnavailableException.java
b/src/java/org/apache/cassandra/exceptions/UnavailableException.java
index e557550..baee0b2 100644
--- a/src/java/org/apache/cassandra/exceptions/UnavailableException.java
+++ b/src/java/org/apache/cassandra/exceptions/UnavailableException.java
@@ -27,7 +27,12 @@ public class UnavailableException extends
RequestExecutionException
public UnavailableException(ConsistencyLevel consistency, int required,
int alive)
{
-super(ExceptionCode.UNAVAILABLE, "Cannot achieve consistency level " +
consistency);
+this("Cannot achieve consistency level " + consistency, consistency,
required, alive);
+}
+
+public UnavailableException(String msg, ConsistencyLevel consistency, int
required, int alive)
+{
+super(ExceptionCode.UNAVAILABLE, msg);
this.consistency = consistency;
this.required = required;
this.alive = alive;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/77df5578/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d8b6619..f877aee 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -304,6 +304,7 @@ public class StorageProxy implements StorageProxyMBean
Token tk = StorageService.getPartitioner().getToken(key);
List naturalEndpoints =
StorageService.instance.getNaturalEndpoints(keyspaceName, tk);
Collection pendingEndpoints =
StorageService.instance.getTokenMetadata().pendingEndpointsFor(tk,
keyspaceName);
+
if (consistencyForPaxos == ConsistencyLevel.LOCAL_SERIAL)
{
// Restrict naturalEndpoints and pendingEndpoints to node in the
local DC only
@@ -312,10 +313,21 @@ public class StorageProxy implements StorageProxyMBean
naturalEndpoints =
ImmutableList.copyOf(Iterables.filter(naturalEndpoints, isLocalDc));
pendingEndpoints =
ImmutableList.copyOf(Iterables.filter(pendingEndpoints, isLocalDc));
}
-int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
+int participants = pendingEndpoints.size() + naturalEndpoints.size();
+int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
List liveEndpoints =
ImmutableList.copyOf(Iterables.filter(Iterables.concat(naturalEndpoints,
pendingEndpoints), IAsyncCallback.isAlive));
if (liveEndpoints.size() < requiredParticipants)
throw new UnavailableException(consistencyForPaxos,
requiredParticipants, liveEndpoints.size());
+
+// We cannot allow CAS operations with 2 or more pending endpoints,
see #8346.
+// Note that we fake an impossible number of required nodes in the
unavailable exception
+// to nail home the point that it's an impossible operation no matter
how many nodes are live.
[jira] [Created] (CASSANDRA-8447) Nodes stuck in CMS GC cycle with very little traffic when compaction is enabled
jonathan lacefield created CASSANDRA-8447: - Summary: Nodes stuck in CMS GC cycle with very little traffic when compaction is enabled Key: CASSANDRA-8447 URL: https://issues.apache.org/jira/browse/CASSANDRA-8447 Project: Cassandra Issue Type: Bug Components: Core Environment: Cluster size - 4 nodes Node size - 12 CPU (hyper threaded to 24 cores), 192 GB RAM, 2 Raid 0 arrays (Data - 10 disk, spinning 10k drives | CL 2 disk, spinning 10k drives) OS - RHEL 6.5 jvm - oracle 1.7.0_71 Cassandra version 2.0.11 Reporter: jonathan lacefield Attachments: Node_with_compaction.png, Node_without_compaction.png, cassandra.yaml, gc.logs.tar.gz, gcinspector_messages.txt, results.tar.gz, visualvm_screenshot Behavior - If autocompaction is enabled, nodes will become unresponsive due to a full Old Gen heap which is not cleared during CMS GC. Test methodology - disabled autocompaction on 3 nodes, left autocompaction enabled on 1 node. Executed different Cassandra stress loads, using write only operations. Monitored visualvm and jconsole for heap pressure. Captured iostat and dstat for most tests. Captured heap dump from 50 thread load. Hints were disabled for testing on all nodes to alleviate GC noise due to hints backing up. Data load test through Cassandra stress - /usr/bin/cassandra-stress write n=19 -rate threads= -schema replication\(factor=3\) keyspace="Keyspace1" -node Data load thread count and results: * 1 thread - Still running but looks like the node can sustain this load (approx 500 writes per second per node) * 5 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 2k writes per second per node) * 10 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range * 50 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 10k writes per second per node) * 100 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range * 200 threads - Nodes become unresponsive due to full Old Gen Heap. CMS measured in the 60 second range (approx 20k writes per second per node) Note - the observed behavior was the same for all tests except for the single threaded test. The single threaded test does not appear to show this behavior. Tested different GC and Linux OS settings with a focus on the 50 and 200 thread loads. JVM settings tested: # default, out of the box, env-sh settings # 10 G Max | 1 G New - default env-sh settings # 10 G Max | 1 G New - default env-sh settings #* JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=50" # 20 G Max | 10 G New JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8" JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=8" JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75" JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS="$JVM_OPTS -XX:+UseTLAB" JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS="$JVM_OPTS -XX:CMSMaxAbortablePrecleanTime=6" JVM_OPTS="$JVM_OPTS -XX:CMSWaitDuration=3" JVM_OPTS="$JVM_OPTS -XX:ParallelGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:ConcGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS="$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS="$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" JVM_OPTS="$JVM_OPTS -XX:ParGCCardsPerStrideChunk=32768" JVM_OPTS="$JVM_OPTS -XX:-UseBiasedLocking" # 20 G Max | 1 G New JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8" JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=8" JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75" JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS="$JVM_OPTS -XX:+UseTLAB" JVM_OPTS="$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS="$JVM_OPTS -XX:CMSMaxAbortablePrecleanTime=6" JVM_OPTS="$JVM_OPTS -XX:CMSWaitDuration=3" JVM_OPTS="$JVM_OPTS -XX:ParallelGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:ConcGCThreads=12" JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS="$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS="$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" JVM_OPTS="$JVM_OPTS -XX:ParGCCardsPerStrideChunk=32768" JVM_OPTS="$JVM_OPTS -XX:-UseBiasedLocking" Linux OS settings tested: # Disabled Transparent Huge Pages echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # Enabled Huge Pages echo 215 > /proc/sys/kernel/shmmax (over 20GB for heap) echo 1536 > /proc/sys/v
cassandra git commit: Fix Accumulator.isEmpty method
Repository: cassandra
Updated Branches:
refs/heads/trunk 9510eb0f3 -> 178d7b6f8
Fix Accumulator.isEmpty method
patch by slebresne; reviewed by benedict for CASSANDRA-7873
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/178d7b6f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/178d7b6f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/178d7b6f
Branch: refs/heads/trunk
Commit: 178d7b6f8837e8f5cdd5f9c4661f3a3c3a0c4c0a
Parents: 9510eb0
Author: Sylvain Lebresne
Authored: Tue Dec 9 20:08:38 2014 +0100
Committer: Sylvain Lebresne
Committed: Tue Dec 9 20:08:38 2014 +0100
--
.../cassandra/utils/concurrent/Accumulator.java | 2 +-
.../utils/concurrent/AccumulatorTest.java | 106 +++
2 files changed, 107 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/178d7b6f/src/java/org/apache/cassandra/utils/concurrent/Accumulator.java
--
diff --git a/src/java/org/apache/cassandra/utils/concurrent/Accumulator.java
b/src/java/org/apache/cassandra/utils/concurrent/Accumulator.java
index 3b5e5c9..baecb34 100644
--- a/src/java/org/apache/cassandra/utils/concurrent/Accumulator.java
+++ b/src/java/org/apache/cassandra/utils/concurrent/Accumulator.java
@@ -89,7 +89,7 @@ public class Accumulator implements Iterable
public boolean isEmpty()
{
-return presentCount != 0;
+return presentCount == 0;
}
/**
http://git-wip-us.apache.org/repos/asf/cassandra/blob/178d7b6f/test/unit/org/apache/cassandra/utils/concurrent/AccumulatorTest.java
--
diff --git
a/test/unit/org/apache/cassandra/utils/concurrent/AccumulatorTest.java
b/test/unit/org/apache/cassandra/utils/concurrent/AccumulatorTest.java
new file mode 100644
index 000..2842374
--- /dev/null
+++ b/test/unit/org/apache/cassandra/utils/concurrent/AccumulatorTest.java
@@ -0,0 +1,106 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+*http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+package org.apache.cassandra.utils.concurrent;
+
+import java.util.Iterator;
+
+import org.junit.Test;
+
+import static org.junit.Assert.*;
+
+public class AccumulatorTest
+{
+@Test
+public void testAddMoreThanCapacity()
+{
+Accumulator accu = new Accumulator(4);
+
+accu.add(1);
+accu.add(2);
+accu.add(3);
+accu.add(4);
+
+try
+{
+accu.add(5);
+fail();
+}
+catch (IllegalStateException e)
+{
+// Expected
+}
+}
+
+@Test
+public void testIsEmptyAndSize()
+{
+Accumulator accu = new Accumulator(4);
+
+assertTrue(accu.isEmpty());
+assertEquals(0, accu.size());
+
+accu.add(1);
+accu.add(2);
+
+assertTrue(!accu.isEmpty());
+assertEquals(2, accu.size());
+
+accu.add(3);
+accu.add(4);
+
+assertTrue(!accu.isEmpty());
+assertEquals(4, accu.size());
+}
+
+@Test
+public void testGetAndIterator()
+{
+Accumulator accu = new Accumulator(4);
+
+accu.add("3");
+accu.add("2");
+accu.add("4");
+
+assertEquals("3", accu.get(0));
+assertEquals("2", accu.get(1));
+assertEquals("4", accu.get(2));
+
+try
+{
+assertEquals(null, accu.get(3));
+fail();
+}
+catch (IndexOutOfBoundsException e)
+{
+// Expected
+}
+
+accu.add("0");
+
+assertEquals("0", accu.get(3));
+
+Iterator iter = accu.iterator();
+
+assertEquals("3", iter.next());
+assertEquals("2", iter.next());
+assertEquals("4", iter.next());
+assertEquals("0", iter.next());
+assertFalse(iter.hasNext());
+}
+}
[jira] [Updated] (CASSANDRA-8194) Reading from Auth table should not be in the request path
[ https://issues.apache.org/jira/browse/CASSANDRA-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishy Kasar updated CASSANDRA-8194: --- Attachment: 8194-V2.patch Thanks for the quick review Aleksey. I have attached 8194-V2.patch that addresses the issues you raised. Let me know if you have any further comments before committing this patch. > Reading from Auth table should not be in the request path > - > > Key: CASSANDRA-8194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8194 > Project: Cassandra > Issue Type: Improvement >Reporter: Vishy Kasar >Priority: Minor > Fix For: 2.0.12, 3.0 > > Attachments: 8194-V2.patch, 8194.patch > > > We use PasswordAuthenticator and PasswordAuthorizer. The system_auth has a RF > of 10 per DC over 2 DCs. The permissions_validity_in_ms is 5 minutes. > We still have few thousand requests failing each day with the trace below. > The reason for this is read cache request realizing that cached entry has > expired and doing a blocking request to refresh cache. > We should have cache refreshed periodically only in the back ground. The user > request should simply look at the cache and not try to refresh it. > com.google.common.util.concurrent.UncheckedExecutionException: > java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2258) > at com.google.common.cache.LocalCache.get(LocalCache.java:3990) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878) > at > org.apache.cassandra.service.ClientState.authorize(ClientState.java:292) > at > org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:172) > at > org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:165) > at > org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:149) > at > org.apache.cassandra.cql3.statements.ModificationStatement.checkAccess(ModificationStatement.java:75) > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:102) > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:113) > at > org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1735) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4162) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4150) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:206) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at org.apache.cassandra.auth.Auth.selectUser(Auth.java:256) > at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:84) > at > org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50) > at > org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:68) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:278) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:275) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589) > at > com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252) > ... 19 more > Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation > timed out - received only 0 responses. > at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:105) > at > org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:943) > at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:828) > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:140) > at org.apache.cassandra.auth.Auth.selectUser(Auth.java:245) >
[jira] [Commented] (CASSANDRA-7882) Memtable slab allocation should scale logarithmically to improve occupancy rate
[ https://issues.apache.org/jira/browse/CASSANDRA-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239891#comment-14239891 ] Benedict commented on CASSANDRA-7882: - Yes, I don't think that's a problem. > Memtable slab allocation should scale logarithmically to improve occupancy > rate > --- > > Key: CASSANDRA-7882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7882 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jay Patel >Assignee: Benedict > Labels: performance > Fix For: 2.1.3 > > Attachments: trunk-7882.txt > > > CASSANDRA-5935 allows option to disable region-based allocation for on-heap > memtables but there is no option to disable it for off-heap memtables > (memtable_allocation_type: offheap_objects). > Disabling region-based allocation will allow us to pack more tables in the > schema since minimum of 1MB region won't be allocated per table. Downside can > be more fragmentation which should be controllable by using better allocator > like JEMalloc. > How about below option in yaml?: > memtable_allocation_type: unslabbed_offheap_objects > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7882) Memtable slab allocation should scale logarithmically to improve occupancy rate
[ https://issues.apache.org/jira/browse/CASSANDRA-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239871#comment-14239871 ] Jay Patel commented on CASSANDRA-7882: -- Ah, CASSANDRA-7883 is for 3.0. Can we have it merge to 2.1.3? > Memtable slab allocation should scale logarithmically to improve occupancy > rate > --- > > Key: CASSANDRA-7882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7882 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jay Patel >Assignee: Benedict > Labels: performance > Fix For: 2.1.3 > > Attachments: trunk-7882.txt > > > CASSANDRA-5935 allows option to disable region-based allocation for on-heap > memtables but there is no option to disable it for off-heap memtables > (memtable_allocation_type: offheap_objects). > Disabling region-based allocation will allow us to pack more tables in the > schema since minimum of 1MB region won't be allocated per table. Downside can > be more fragmentation which should be controllable by using better allocator > like JEMalloc. > How about below option in yaml?: > memtable_allocation_type: unslabbed_offheap_objects > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239869#comment-14239869
]
Andrew Garrett commented on CASSANDRA-8430:
---
[~aboudreault] Although that surprises me, it explains what I was seeing, sort
of. I also perceived confusing behavior when it came to setting things to null:
if I set everything to null on a row in a table where there were no primitive
types like bigint then the row would remain, and its contents would all be
null. But if I did this on a row that did contain primitive types then the row
would be removed. On the other hand, in both cases, TTLs would purge the column
as expected, but my understanding is that TTLs mark a column with a tombstone
whereas setting things to null just... sets them to null. So I don't understand
this behavior and I also don't understand why, if the primary key isn't a
normal column, it will remain around as long as the row doesn't contain
primitives in this case I'm explaining. These two situations feel related, are
they?
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7882) Memtable slab allocation should scale logarithmically to improve occupancy rate
[ https://issues.apache.org/jira/browse/CASSANDRA-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239863#comment-14239863 ] Jay Patel commented on CASSANDRA-7882: -- Thanks [~benedict]. Changes look good except I see it uses unsafe.allocateMemory directly instead of IAllocator interface (CASSANDRA-7883). We're planning to run load test with this final patch from next week. > Memtable slab allocation should scale logarithmically to improve occupancy > rate > --- > > Key: CASSANDRA-7882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7882 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jay Patel >Assignee: Benedict > Labels: performance > Fix For: 2.1.3 > > Attachments: trunk-7882.txt > > > CASSANDRA-5935 allows option to disable region-based allocation for on-heap > memtables but there is no option to disable it for off-heap memtables > (memtable_allocation_type: offheap_objects). > Disabling region-based allocation will allow us to pack more tables in the > schema since minimum of 1MB region won't be allocated per table. Downside can > be more fragmentation which should be controllable by using better allocator > like JEMalloc. > How about below option in yaml?: > memtable_allocation_type: unslabbed_offheap_objects > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239826#comment-14239826
]
Alan Boudreault edited comment on CASSANDRA-8430 at 12/9/14 6:57 PM:
-
[~angarrett] I think your confusion is due to the the fact that you consider
the *PRIMARY KEY* as a normal column, when it is not. We cannot delete the
primary key *column* without deleting ALL other columns. The TTL of the Primary
Key (or row) is MAX(all_column_ttls), 0 being considered as infinity, so the
higher. So it is normal that modifying a column ttl with a lower ttl doesn't
affect the row TTL. Does it make sense? [~slebresne] can confirm if I'm right
too.
was (Author: aboudreault):
[~angarrett] I think your confusion is due to the the fact that you consider
the *PRIMARY KEY* as a column, when it is not. We cannot delete the primary key
*column* without deleting ALL other columns. The TTL of the Primary Key (or
row) is MAX(all_column_ttls), 0 being considered as infinity, so the higher. So
it is normal that modifying a column ttl with a lower ttl doesn't affect the
row TTL. Does it make sense? [~slebresne] can confirm if I'm right too.
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8061:
---
Reproduced In: 2.1.1, 2.1.0 (was: 2.1.0, 2.1.1)
Tester: Philip Thompson
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8061_v1.txt, 8248-thread_dump.txt
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Index.db
> 137M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Data.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Data.db
> 139M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Data.db
> 940K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Index.db
> 936K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Index.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Data.db
> 672K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Index.db
> 113M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Data.db
> 116M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/drai
[jira] [Comment Edited] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239826#comment-14239826
]
Alan Boudreault edited comment on CASSANDRA-8430 at 12/9/14 6:56 PM:
-
[~angarrett] I think your confusion is due to the the fact that you consider
the *PRIMARY KEY* as a column, when it is not. We cannot delete the primary key
*column* without deleting ALL other columns. The TTL of the Primary Key (or
row) is MAX(all_column_ttls), 0 being considered as infinity, so the higher. So
it is normal that modifying a column ttl with a lower ttl doesn't affect the
row TTL. Does it make sense? [~slebresne] can confirm if I'm right too.
was (Author: aboudreault):
[~angarrett] I think your confusion is due to the the fact that you consider
the *PRIMARY KEY* as a column, when it is not. The TTL of the Primary Key (or
row) is MAX(all_column_ttls), 0 being considered as infinity, so the higher. So
it is normal that modifying a column ttl with a lower ttl doesn't affect the
row TTL. Does it make sense? [~slebresne] can confirm if I'm right too.
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239826#comment-14239826
]
Alan Boudreault commented on CASSANDRA-8430:
[~angarrett] I think your confusion is due to the the fact that you consider
the *PRIMARY KEY* as a column, when it is not. The TTL of the Primary Key (or
row) is MAX(all_column_ttls), 0 being considered as infinity, so the higher. So
it is normal that modifying a column ttl with a lower ttl doesn't affect the
row TTL. Does it make sense? [~slebresne] can confirm if I'm right too.
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8446) Lost writes when using lightweight transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-8446: --- Reproduced In: 2.1.2 Fix Version/s: 2.1.3 > Lost writes when using lightweight transactions > --- > > Key: CASSANDRA-8446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8446 > Project: Cassandra > Issue Type: Bug > Components: API, Core > Environment: Cassandra 2.1.2 on Java(TM) SE Runtime Environment > (build 1.7.0_65-b17) >Reporter: Jochen Zeischka > Fix For: 2.1.3 > > > There's a serious problem when using lightweight transactions. Whenever th > cluster gets any load, write timeout exceptions start to occur and the client > has no way to know whether the write actually succeeded or not. > I a simple test (https://gist.github.com/anonymous/4c83f2962b57fce4c3df) this > results in large percentages of lost writes (0 - 50%, depending on the load). > The problem was described in > https://stackoverflow.com/questions/27313360/how-can-we-avoid-losing-writes-when-using-lightweight-transactions-cas-in-cass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8261) Clean up schema metadata classes
[ https://issues.apache.org/jira/browse/CASSANDRA-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239810#comment-14239810 ] Tyler Hobbs commented on CASSANDRA-8261: Some of the function-related changes in the patch need to be rebased. I'll go ahead and start reviewing it, though. > Clean up schema metadata classes > > > Key: CASSANDRA-8261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8261 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0 > > Attachments: 8261-isolate-hadcoded-system-tables.txt, > 8261-isolate-serialization-code.txt, 8261-isolate-thrift-code.txt > > > While working on CASSANDRA-6717, I've made some general cleanup changes to > schema metadata classes - distracted from the core purpose. Also, being > distracted from it by other things, every time I come back to it gives me a > bit of a rebase hell. > Thus I'm isolating those changes into a separate issue here, hoping to commit > them one by one, before I go back and finalize CASSANDRA-6717. > The changes include: > - moving all the toThrift/fromThrift conversion code to ThriftConversion, > where it belongs > - moving the complied system CFMetaData objects away from CFMetaData (to > SystemKeyspace and TracesKeyspace) > - isolating legacy toSchema/fromSchema code into a separate class > (LegacySchemaTables - former DefsTables) > - refactoring CFMetaData/KSMetaData fields to match CQL CREATE TABLE syntax, > and encapsulating more things in > CompactionOptions/CompressionOptions/ReplicationOptions classes > - moving the definition classes to the new 'schema' package -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8427) An error is written to System.out when UserTypesTest is run
[
https://issues.apache.org/jira/browse/CASSANDRA-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239806#comment-14239806
]
Tyler Hobbs commented on CASSANDRA-8427:
I'm still getting stacktraces printed when running UserTypesTest because some
of the UDTs are still used by tables. We need to track tables to drop in the
same way we track types and functions.
> An error is written to System.out when UserTypesTest is run
> ---
>
> Key: CASSANDRA-8427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8427
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Minor
> Fix For: 3.0, 2.1.3
>
> Attachments: CASSANDRA-8427-2.1.txt, CASSANDRA-8427-trunk.txt
>
>
> When running {{org.apache.cassandra.cql3.UserTypesTest}} the following error
> is printed out to the console.
> {code}ERROR 09:58:41 Fatal exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: Error setting schema
> for test (query was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:188)
> ~[classes/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> Caused by: java.lang.RuntimeException: Error setting schema for test (query
> was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:413)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester.access$3(CQLTester.java:404)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:167)
> ~[classes/:na]
> ... 7 common frames omitted
> Caused by: java.lang.RuntimeException: Error validating query DROP TYPE IF
> EXISTS cql_test_keyspace.type_2
> at
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:374)
> ~[main/:na]
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:409)
> ~[classes/:na]
> ... 9 common frames omitted
> Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Cannot
> drop user type cql_test_keyspace.type_2 as it is still used by user type
> type_3
> at
> org.apache.cassandra.cql3.statements.DropTypeStatement.validate(DropTypeStatement.java:93)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:361)
> ~[main/:na]
> ... 10 common frames omitted
> ERROR 09:58:41 Fatal exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: Error setting schema
> for test (query was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:188)
> ~[classes/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> Caused by: java.lang.RuntimeException: Error setting schema for test (query
> was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:413)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester.access$3(CQLTester.java:404)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:167)
> ~[classes/:na]
> ... 7 common frames omitted
> Caused by: java.lang.RuntimeException
[jira] [Commented] (CASSANDRA-8438) Nested collections not serialized with respect to native protocol version
[
https://issues.apache.org/jira/browse/CASSANDRA-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239804#comment-14239804
]
Adam Holmberg commented on CASSANDRA-8438:
--
A tag could work. I was aware of CASSANDRA-8043 for keeping an eye on new
protocol updates, but as you say it would also be useful to be aware of
impactful serialization decisions.
> Nested collections not serialized with respect to native protocol version
> -
>
> Key: CASSANDRA-8438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8438
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Adam Holmberg
>Priority: Minor
>
> It appears that inner collections are not encoding collection element count
> correctly for protocol version <=2
> {code}
> from cassandra.cluster import Cluster
> s = Cluster(protocol_version=2).connect()
> s.execute("CREATE KEYSPACE test WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': '1'}")
> s.execute("CREATE TABLE test.test (k int PRIMARY KEY, v map frozen>>)
> s.execute("INSERT INTO test.test (k, v ) VALUES ( 1, {1: [2,3,4]})")
> print s.execute("SELECT * FROM test.test")
> {code}
> The map returned is encoded as follows:
> 00:01:00:04:00:00:00:01:00:1c:*00:00:00:03*:*00:00:00:04*:00:00:00:02:*00:00:00:04*:00:00:00:03:*00:00:00:04*:00:00:00:04
> It appears that the outer collection encoding is as expected, while the inner
> list count, and list element sizes are _int_ size, instead of _short_. This
> does not manifest as a problem in cqlsh because it uses protocol version 3 by
> default, which accepts this encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239797#comment-14239797
]
Andrew Garrett commented on CASSANDRA-8430:
---
[~slebresne] Hi, I am the initial asker of the StackOverflow question. My
confusion is with the fact that it seems that the primary key column had its
TTL updated. If I said that the TTL was 60 seconds when I insert the row, then
shouldn't the primary key column have a TTL of 60? Yet it seems like its TTL
gets updated if any updates are done on that row which specify a TTL which is 0
or is greater than the current TTL, but if the update specifies a TTL which is
lower than the current TTL, then no change occurs.
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8438) Nested collections not serialized with respect to native protocol version
[
https://issues.apache.org/jira/browse/CASSANDRA-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239768#comment-14239768
]
Tyler Hobbs commented on CASSANDRA-8438:
bq. That's fair. Thanks for the info. Where should a person look to find out
about decisions like this?
That's a good question. It's technically a protocol-independent change, so I
guess each of the native protocol specs should have their section on collection
serialization updated.
However, that's not the most useful way to alert driver authors to changes like
this. Perhaps we should use a tag for any JIRA issues that affect the native
protocol or type serialization?
> Nested collections not serialized with respect to native protocol version
> -
>
> Key: CASSANDRA-8438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8438
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Adam Holmberg
>Priority: Minor
>
> It appears that inner collections are not encoding collection element count
> correctly for protocol version <=2
> {code}
> from cassandra.cluster import Cluster
> s = Cluster(protocol_version=2).connect()
> s.execute("CREATE KEYSPACE test WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': '1'}")
> s.execute("CREATE TABLE test.test (k int PRIMARY KEY, v map frozen>>)
> s.execute("INSERT INTO test.test (k, v ) VALUES ( 1, {1: [2,3,4]})")
> print s.execute("SELECT * FROM test.test")
> {code}
> The map returned is encoded as follows:
> 00:01:00:04:00:00:00:01:00:1c:*00:00:00:03*:*00:00:00:04*:00:00:00:02:*00:00:00:04*:00:00:00:03:*00:00:00:04*:00:00:00:04
> It appears that the outer collection encoding is as expected, while the inner
> list count, and list element sizes are _int_ size, instead of _short_. This
> does not manifest as a problem in cqlsh because it uses protocol version 3 by
> default, which accepts this encoding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
[ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239729#comment-14239729 ] Ariel Weisberg commented on CASSANDRA-7438: --- Lot's of cool stuff here Robert. Unit test wise there is a lot of code that is only covered indirectly or not at all and the behaviors are not checked for explicitly. I don't think it makes sense to include code that doesn't doesn't have a unit test claiming it does what is says it does. The various input/output streams, buffering, and compression all need units tests. Uns.java needs a unit test for pretty much every method as well as the validation functionality. HashEntry has a bunch of uncovered functions. For me the lack of test coverage is the biggest barrier. What I am reacting to is that the tests are black box and miss things. OffHeapMap containsEntry has no tests. removeEntry has untested code. removeLink still has untested code. There is untested histogram stuff, deserializeEntry, serializeEntry. HashEntry classes have untested functions. HashEntries has many predicates that are untested. Having a unit test that fuzzes against a parallel implementation at the same time using a different LRU map implementation would be great for a black box test. You can stripe the other implementation the same way so that the eviction matches. One of my previous comments was that SegmentCacheImpl duplicates reference counting code from OffHeapMap and should just delegate. It ends up doing that anyways. I would really like to see the cleanup/eviction code go away. If inserting an entry would blow capacity remove entries until it doesn't. I don't see a reason to monkey with thresholds. At some point the existing C* cache interface needs to gel with your work. Right now C* uses the hotN and getKeys interface to return the contents of the cache for persistence. I think the path of least resistance to start would be to implement the existing interface and then come back and look at how to get compression and more efficient IO into all the implementations. The existing stuff in C* doesn't do compression and doesn't buffer its IO. I would prefer to minimize major changes to the existing C* code. I want to get it working and then iterate further for other improvements like more efficient cache serialization. You could change the OHC interface or implement an adapter. I think it's fine to modify ICache to return iterables or iterators instead of a collections to incrementally produce key set and hot keys. For everything else I would really like to see things to stay the same unless there is something to be gained by changing the interface. > Serializing Row cache alternative (Fully off heap) > -- > > Key: CASSANDRA-7438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7438 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: Linux >Reporter: Vijay >Assignee: Vijay > Labels: performance > Fix For: 3.0 > > Attachments: 0001-CASSANDRA-7438.patch, tests.zip > > > Currently SerializingCache is partially off heap, keys are still stored in > JVM heap as BB, > * There is a higher GC costs for a reasonably big cache. > * Some users have used the row cache efficiently in production for better > results, but this requires careful tunning. > * Overhead in Memory for the cache entries are relatively high. > So the proposal for this ticket is to move the LRU cache logic completely off > heap and use JNI to interact with cache. We might want to ensure that the new > implementation match the existing API's (ICache), and the implementation > needs to have safe memory access, low overhead in memory and less memcpy's > (As much as possible). > We might also want to make this cache configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8312) Use live sstables in snapshot repair if possible
[ https://issues.apache.org/jira/browse/CASSANDRA-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239638#comment-14239638 ] Benedict commented on CASSANDRA-8312: - bq. it should be enough to just remove the row sstable.acquireReference() Yes, agreed. But I'll let Yuki review and make that change since he's more familiar with this area of the codebase. > Use live sstables in snapshot repair if possible > > > Key: CASSANDRA-8312 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8312 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12, 3.0, 2.1.3 > > Attachments: cassandra-2.0-8312-1.txt > > > Snapshot repair can be very much slower than parallel repairs because of the > overhead of opening the SSTables in the snapshot. This is particular true > when using LCS, as you typically have many smaller SSTables then. > I compared parallel and sequential repair on a small range on one of our > clusters (2*3 replicas). With parallel repair, this took 22 seconds. With > sequential repair (default in 2.0), the same range took 330 seconds! This is > an overhead of 330-22*6 = 198 seconds, just opening SSTables (there were > 1000+ sstables). Also, opening 1000 sstables for many smaller rangers surely > causes lots of memory churning. > The idea would be to list the sstables in the snapshot, but use the > corresponding sstables in the live set if it's still available. For almost > all sstables, the original one should still exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8414) Avoid loops over array backed iterators that call iter.remove()
[ https://issues.apache.org/jira/browse/CASSANDRA-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-8414: Attachment: cassandra-2.0-8414-3.txt Nice backporting of the better approach. I've uploaded a tweaked version, the goal of which was just to clean up the variable names (and switch to a while loop) so it's more obvious what's happening. But while at it I also added use of nextClearBit in tandem with nextSetBit, as it's a minor tweak but gives better behaviour with runs of adjacent removes. I haven't properly reviewed otherwise, but it might be worth introducing this to CFS.removeDroppedColumns() and SliceQueryFilter.trim(), > Avoid loops over array backed iterators that call iter.remove() > --- > > Key: CASSANDRA-8414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8414 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Richard Low >Assignee: Jimmy Mårdell > Labels: performance > Fix For: 2.1.3 > > Attachments: cassandra-2.0-8414-1.txt, cassandra-2.0-8414-2.txt, > cassandra-2.0-8414-3.txt > > > I noticed from sampling that sometimes compaction spends almost all of its > time in iter.remove() in ColumnFamilyStore.removeDeletedStandard. It turns > out that the cf object is using ArrayBackedSortedColumns, so deletes are from > an ArrayList. If the majority of your columns are GCable tombstones then this > is O(n^2). The data structure should be changed or a copy made to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8194) Reading from Auth table should not be in the request path
[ https://issues.apache.org/jira/browse/CASSANDRA-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239586#comment-14239586 ] Jeremiah Jordan commented on CASSANDRA-8194: Do we care that if this never updates, we will keep using the cached stuff indefinitely? That is the only possible problem I see here. > Reading from Auth table should not be in the request path > - > > Key: CASSANDRA-8194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8194 > Project: Cassandra > Issue Type: Improvement >Reporter: Vishy Kasar >Priority: Minor > Fix For: 2.0.12, 3.0 > > Attachments: 8194.patch > > > We use PasswordAuthenticator and PasswordAuthorizer. The system_auth has a RF > of 10 per DC over 2 DCs. The permissions_validity_in_ms is 5 minutes. > We still have few thousand requests failing each day with the trace below. > The reason for this is read cache request realizing that cached entry has > expired and doing a blocking request to refresh cache. > We should have cache refreshed periodically only in the back ground. The user > request should simply look at the cache and not try to refresh it. > com.google.common.util.concurrent.UncheckedExecutionException: > java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2258) > at com.google.common.cache.LocalCache.get(LocalCache.java:3990) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878) > at > org.apache.cassandra.service.ClientState.authorize(ClientState.java:292) > at > org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:172) > at > org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:165) > at > org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:149) > at > org.apache.cassandra.cql3.statements.ModificationStatement.checkAccess(ModificationStatement.java:75) > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:102) > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:113) > at > org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1735) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4162) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4150) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:206) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at org.apache.cassandra.auth.Auth.selectUser(Auth.java:256) > at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:84) > at > org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50) > at > org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:68) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:278) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:275) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589) > at > com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252) > ... 19 more > Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation > timed out - received only 0 responses. > at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:105) > at > org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:943) > at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:828) > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:140) > at org.apache.cassandra.auth.Auth.selectUser(Auth.java:245) > ... 28 more > ERROR [
[jira] [Commented] (CASSANDRA-8346) Paxos operation can use stale data during multiple range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239562#comment-14239562
]
Koen Janssens commented on CASSANDRA-8346:
--
If I look at the changes in the attachment, I see that the changes made in
"getPaxosParticipants" has an impact on method "readWithPaxos" in the
StorageProxy. I'm not familiar with the codebase so I could be mistaken, but it
would explain why we see problems with lightweight transactions when we use a
replication factor of 3 and we don't see that problem surfacing with a
replication factor of 2.
> Paxos operation can use stale data during multiple range movements
> --
>
> Key: CASSANDRA-8346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8346
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments: 8346.txt
>
>
> Paxos operations correctly account for pending ranges for all operation
> pertaining to the Paxos state, but those pending ranges are not taken into
> account when reading the data to check for the conditions or during a serial
> read. It's thus possible to break the LWT guarantees by reading a stale
> value. This require 2 node movements (on the same token range) to be a
> problem though.
> Basically, we have {{RF}} replicas + {{P}} pending nodes. For the Paxos
> prepare/propose phases, the number of required participants (the "Paxos
> QUORUM") is {{(RF + P + 1) / 2}} ({{SP.getPaxosParticipants}}), but the read
> done to check conditions or for serial reads is done at a "normal" QUORUM (or
> LOCAL_QUORUM), and so a weaker {{(RF + 1) / 2}}. We have a problem if it's
> possible that said read can read only from nodes that were not part of the
> paxos participants, and so we have a problem if:
> {noformat}
> "normal quorum" == (RF + 1) / 2 <= (RF + P) - ((RF + P + 1) / 2) ==
> "participants considered - blocked for"
> {noformat}
> We're good if {{P = 0}} or {{P = 1}} since this inequality gives us
> respectively {{RF + 1 <= RF - 1}} and {{RF + 1 <= RF}}, both of which are
> impossible. But at {{P = 2}} (2 pending nodes), this inequality is equivalent
> to {{RF <= RF}} and so we might read stale data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8414) Avoid loops over array backed iterators that call iter.remove()
[ https://issues.apache.org/jira/browse/CASSANDRA-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Mårdell updated CASSANDRA-8414: - Attachment: cassandra-2.0-8414-2.txt > Avoid loops over array backed iterators that call iter.remove() > --- > > Key: CASSANDRA-8414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8414 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Richard Low >Assignee: Jimmy Mårdell > Labels: performance > Fix For: 2.1.3 > > Attachments: cassandra-2.0-8414-1.txt, cassandra-2.0-8414-2.txt > > > I noticed from sampling that sometimes compaction spends almost all of its > time in iter.remove() in ColumnFamilyStore.removeDeletedStandard. It turns > out that the cf object is using ArrayBackedSortedColumns, so deletes are from > an ArrayList. If the majority of your columns are GCable tombstones then this > is O(n^2). The data structure should be changed or a copy made to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8414) Avoid loops over array backed iterators that call iter.remove()
[ https://issues.apache.org/jira/browse/CASSANDRA-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239555#comment-14239555 ] Jimmy Mårdell commented on CASSANDRA-8414: -- Good point. I've attached a new patch containing code using removed.nextSetBit and Collections.copy. Should be easy now to change for 2.1. > Avoid loops over array backed iterators that call iter.remove() > --- > > Key: CASSANDRA-8414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8414 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Richard Low >Assignee: Jimmy Mårdell > Labels: performance > Fix For: 2.1.3 > > Attachments: cassandra-2.0-8414-1.txt, cassandra-2.0-8414-2.txt > > > I noticed from sampling that sometimes compaction spends almost all of its > time in iter.remove() in ColumnFamilyStore.removeDeletedStandard. It turns > out that the cf object is using ArrayBackedSortedColumns, so deletes are from > an ArrayList. If the majority of your columns are GCable tombstones then this > is O(n^2). The data structure should be changed or a copy made to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8194) Reading from Auth table should not be in the request path
[ https://issues.apache.org/jira/browse/CASSANDRA-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239526#comment-14239526 ] Aleksey Yeschenko commented on CASSANDRA-8194: -- All right. Can accept something like it as a temporary measure until a proper solution lands in 3.0. [~vkasar] A few issues: 1. The patch does not apply to 2.0 head 2. Wrong imports order in ClientState - please follow the proper code style (https://wiki.apache.org/cassandra/CodeStyle) 3. Please don't add another executor. Gods know we have too many threads already. Look at using SS.tasks instead. > Reading from Auth table should not be in the request path > - > > Key: CASSANDRA-8194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8194 > Project: Cassandra > Issue Type: Improvement >Reporter: Vishy Kasar >Priority: Minor > Fix For: 2.0.12, 3.0 > > Attachments: 8194.patch > > > We use PasswordAuthenticator and PasswordAuthorizer. The system_auth has a RF > of 10 per DC over 2 DCs. The permissions_validity_in_ms is 5 minutes. > We still have few thousand requests failing each day with the trace below. > The reason for this is read cache request realizing that cached entry has > expired and doing a blocking request to refresh cache. > We should have cache refreshed periodically only in the back ground. The user > request should simply look at the cache and not try to refresh it. > com.google.common.util.concurrent.UncheckedExecutionException: > java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2258) > at com.google.common.cache.LocalCache.get(LocalCache.java:3990) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878) > at > org.apache.cassandra.service.ClientState.authorize(ClientState.java:292) > at > org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:172) > at > org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:165) > at > org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:149) > at > org.apache.cassandra.cql3.statements.ModificationStatement.checkAccess(ModificationStatement.java:75) > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:102) > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:113) > at > org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1735) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4162) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4150) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:206) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.RuntimeException: > org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - > received only 0 responses. > at org.apache.cassandra.auth.Auth.selectUser(Auth.java:256) > at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:84) > at > org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50) > at > org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:68) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:278) > at org.apache.cassandra.service.ClientState$1.load(ClientState.java:275) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589) > at > com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252) > ... 19 more > Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation > timed out - received only 0 responses. > at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:105) > at > org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:943) >
[jira] [Commented] (CASSANDRA-8316) "Did not get positive replies from all endpoints" error on incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239522#comment-14239522 ] Alan Boudreault commented on CASSANDRA-8316: [~yukim] Yes, will do today during my bootcamp breaks. Something that I'm thinking is - if the patch at least avoid the high CPU utilization on failure, it might bean acceptable fix. Will get back to you asap > "Did not get positive replies from all endpoints" error on incremental repair > -- > > Key: CASSANDRA-8316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8316 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: cassandra 2.1.2 >Reporter: Loic Lambiel >Assignee: Marcus Eriksson > Fix For: 2.1.3 > > Attachments: 0001-patch.patch, > CassandraDaemon-2014-11-25-2.snapshot.tar.gz, test.sh > > > Hi, > I've got an issue with incremental repairs on our production 15 nodes 2.1.2 > (new cluster, not yet loaded, RF=3) > After having successfully performed an incremental repair (-par -inc) on 3 > nodes, I started receiving "Repair failed with error Did not get positive > replies from all endpoints." from nodetool on all remaining nodes : > [2014-11-14 09:12:36,488] Starting repair command #3, repairing 108 ranges > for keyspace (seq=false, full=false) > [2014-11-14 09:12:47,919] Repair failed with error Did not get positive > replies from all endpoints. > All the nodes are up and running and the local system log shows that the > repair commands got started and that's it. > I've also noticed that soon after the repair, several nodes started having > more cpu load indefinitely without any particular reason (no tasks / queries, > nothing in the logs). I then restarted C* on these nodes and retried the > repair on several nodes, which were successful until facing the issue again. > I tried to repro on our 3 nodes preproduction cluster without success > It looks like I'm not the only one having this issue: > http://www.mail-archive.com/user%40cassandra.apache.org/msg39145.html > Any idea? > Thanks > Loic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8312) Use live sstables in snapshot repair if possible
[ https://issues.apache.org/jira/browse/CASSANDRA-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239488#comment-14239488 ] Jimmy Mårdell commented on CASSANDRA-8312: -- Were the references you refer to added in 2.1? I notice that 2.1 does a SSTableReader.releaseReferences(sstables); on the snapshots sstables which (before my patch) wasn't the case on 2.0. If so, it should be enough to just remove the row sstable.acquireReference(); in getSnapshotSSTableReader on the 2.1/trunk branches. > Use live sstables in snapshot repair if possible > > > Key: CASSANDRA-8312 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8312 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12, 3.0, 2.1.3 > > Attachments: cassandra-2.0-8312-1.txt > > > Snapshot repair can be very much slower than parallel repairs because of the > overhead of opening the SSTables in the snapshot. This is particular true > when using LCS, as you typically have many smaller SSTables then. > I compared parallel and sequential repair on a small range on one of our > clusters (2*3 replicas). With parallel repair, this took 22 seconds. With > sequential repair (default in 2.0), the same range took 330 seconds! This is > an overhead of 330-22*6 = 198 seconds, just opening SSTables (there were > 1000+ sstables). Also, opening 1000 sstables for many smaller rangers surely > causes lots of memory churning. > The idea would be to list the sstables in the snapshot, but use the > corresponding sstables in the live set if it's still available. For almost > all sstables, the original one should still exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8316) "Did not get positive replies from all endpoints" error on incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239473#comment-14239473 ] Yuki Morishita commented on CASSANDRA-8316: --- Can you get yourkit snapshot for the patced 2.1? It may show something. > "Did not get positive replies from all endpoints" error on incremental repair > -- > > Key: CASSANDRA-8316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8316 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: cassandra 2.1.2 >Reporter: Loic Lambiel >Assignee: Marcus Eriksson > Fix For: 2.1.3 > > Attachments: 0001-patch.patch, > CassandraDaemon-2014-11-25-2.snapshot.tar.gz, test.sh > > > Hi, > I've got an issue with incremental repairs on our production 15 nodes 2.1.2 > (new cluster, not yet loaded, RF=3) > After having successfully performed an incremental repair (-par -inc) on 3 > nodes, I started receiving "Repair failed with error Did not get positive > replies from all endpoints." from nodetool on all remaining nodes : > [2014-11-14 09:12:36,488] Starting repair command #3, repairing 108 ranges > for keyspace (seq=false, full=false) > [2014-11-14 09:12:47,919] Repair failed with error Did not get positive > replies from all endpoints. > All the nodes are up and running and the local system log shows that the > repair commands got started and that's it. > I've also noticed that soon after the repair, several nodes started having > more cpu load indefinitely without any particular reason (no tasks / queries, > nothing in the logs). I then restarted C* on these nodes and retried the > repair on several nodes, which were successful until facing the issue again. > I tried to repro on our 3 nodes preproduction cluster without success > It looks like I'm not the only one having this issue: > http://www.mail-archive.com/user%40cassandra.apache.org/msg39145.html > Any idea? > Thanks > Loic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239455#comment-14239455
]
Yuki Morishita commented on CASSANDRA-7124:
---
It's going to be easier to review if you can create github branch and done all
your planned work there, then post the link to it here.
Thanks.
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: 7124-wip.txt, cassandra-trunk-compact-7124.txt,
> cassandra-trunk-decommission-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239452#comment-14239452
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-7124:
-
[~yukim], Please find attached the patch for the decommission task. There was
no test case for this and I have added one. Since this is a process of
decommissioning one node from a ring, I could not test this as I have only a
single machine with me. Before applying this patch, please apply the patch for
the compact task I had attached earlier. The reason is that there is one new
class file creation happening in that patch (Runner.java). Please let me know
if you have any comments. Thanks
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: 7124-wip.txt, cassandra-trunk-compact-7124.txt,
> cassandra-trunk-decommission-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajanarayanan Thottuvaikkatumana updated CASSANDRA-7124:
Attachment: cassandra-trunk-decommission-7124.txt
Patch for the decommission task
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: 7124-wip.txt, cassandra-trunk-compact-7124.txt,
> cassandra-trunk-decommission-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7705) Safer Resource Management
[ https://issues.apache.org/jira/browse/CASSANDRA-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239408#comment-14239408 ] Benedict commented on CASSANDRA-7705: - I have updated the repository with a rebased version, with some improved comments and a debug mode. This is essentially free given java's object alignment behaviour and run time optimisation (the field doesn't occupy any memory we wouldn't otherwise be occupying, and the relevant statements will be optimised away). > Safer Resource Management > - > > Key: CASSANDRA-7705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7705 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict > Fix For: 3.0 > > > We've had a spate of bugs recently with bad reference counting. these can > have potentially dire consequences, generally either randomly deleting data > or giving us infinite loops. > Since in 2.1 we only reference count resources that are relatively expensive > and infrequently managed (or in places where this safety is probably not as > necessary, e.g. SerializingCache), we could without any negative consequences > (and only slight code complexity) introduce a safer resource management > scheme for these more expensive/infrequent actions. > Basically, I propose when we want to acquire a resource we allocate an object > that manages the reference. This can only be released once; if it is released > twice, we fail immediately at the second release, reporting where the bug is > (rather than letting it continue fine until the next correct release corrupts > the count). The reference counter remains the same, but we obtain guarantees > that the reference count itself is never badly maintained, although code > using it could mistakenly release its own handle early (typically this is > only an issue when cleaning up after a failure, in which case under the new > scheme this would be an innocuous error) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/3] cassandra git commit: Throw correct exception when trying to bind a keyspace or table name
Repository: cassandra
Updated Branches:
refs/heads/trunk 7d9acdb10 -> 9510eb0f3
Throw correct exception when trying to bind a keyspace or table name
patch by Benjamin Lerer; reviewed by Aleksey Yeschenko for
CASSANDRA-6952
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71e1219d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71e1219d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71e1219d
Branch: refs/heads/trunk
Commit: 71e1219de71fe341316f8cab2f5faeea37ceff1e
Parents: c26a7e7
Author: Benjamin Lerer
Authored: Tue Dec 9 13:56:25 2014 +0100
Committer: Aleksey Yeschenko
Committed: Tue Dec 9 13:56:25 2014 +0100
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/cql3/Cql.g | 1 +
2 files changed, 3 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e1219d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5573316..7c89e60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.0.12:
+ * Throw correct exception when trying to bind a keyspace or table
+ name (CASSANDRA-6952)
* Make HHOM.compact synchronized (CASSANDRA-8416)
* cancel latency-sampling task when CF is dropped (CASSANDRA-8401)
* don't block SocketThread for MessagingService (CASSANDRA-8188)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e1219d/src/java/org/apache/cassandra/cql3/Cql.g
--
diff --git a/src/java/org/apache/cassandra/cql3/Cql.g
b/src/java/org/apache/cassandra/cql3/Cql.g
index 43b1c01..a80746c 100644
--- a/src/java/org/apache/cassandra/cql3/Cql.g
+++ b/src/java/org/apache/cassandra/cql3/Cql.g
@@ -771,6 +771,7 @@ cfOrKsName[CFName name, boolean isKs]
: t=IDENT { if (isKs) $name.setKeyspace($t.text, false); else
$name.setColumnFamily($t.text, false); }
| t=QUOTED_NAME{ if (isKs) $name.setKeyspace($t.text, true); else
$name.setColumnFamily($t.text, true); }
| k=unreserved_keyword { if (isKs) $name.setKeyspace(k, false); else
$name.setColumnFamily(k, false); }
+| QMARK {addRecognitionError("Bind variables cannot be used for keyspace
or table names");}
;
constant returns [Constants.Literal constant]
[3/3] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9510eb0f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9510eb0f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9510eb0f Branch: refs/heads/trunk Commit: 9510eb0f3cf9f3cb085c218242e31627c37383b9 Parents: 7d9acdb 7fa0341 Author: Aleksey Yeschenko Authored: Tue Dec 9 13:59:56 2014 +0100 Committer: Aleksey Yeschenko Committed: Tue Dec 9 13:59:56 2014 +0100 -- CHANGES.txt | 2 ++ src/java/org/apache/cassandra/cql3/Cql.g| 1 + .../org/apache/cassandra/cql3/CQLTester.java| 25 +++-- .../apache/cassandra/cql3/UseStatementTest.java | 29 4 files changed, 54 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9510eb0f/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9510eb0f/src/java/org/apache/cassandra/cql3/Cql.g -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9510eb0f/test/unit/org/apache/cassandra/cql3/CQLTester.java --
[2/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7fa03413 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7fa03413 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7fa03413 Branch: refs/heads/trunk Commit: 7fa034136a96aab4a8ca5173751bdb52bcbca500 Parents: c1610f6 71e1219 Author: Aleksey Yeschenko Authored: Tue Dec 9 13:59:18 2014 +0100 Committer: Aleksey Yeschenko Committed: Tue Dec 9 13:59:18 2014 +0100 -- CHANGES.txt | 2 ++ src/java/org/apache/cassandra/cql3/Cql.g| 1 + .../org/apache/cassandra/cql3/CQLTester.java| 25 +++-- .../apache/cassandra/cql3/UseStatementTest.java | 29 4 files changed, 54 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fa03413/CHANGES.txt -- diff --cc CHANGES.txt index b8d2ff6,7c89e60..28dd6b4 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,23 -1,6 +1,25 @@@ -2.0.12: +2.1.3 + * Reduce maxHintsInProgress (CASSANDRA-8415) + * BTree updates may call provided update function twice (CASSANDRA-8018) + * Release sstable references after anticompaction (CASSANDRA-8386) + * Handle abort() in SSTableRewriter properly (CASSANDRA-8320) + * Fix high size calculations for prepared statements (CASSANDRA-8231) + * Centralize shared executors (CASSANDRA-8055) + * Fix filtering for CONTAINS (KEY) relations on frozen collection + clustering columns when the query is restricted to a single + partition (CASSANDRA-8203) + * Do more aggressive entire-sstable TTL expiry checks (CASSANDRA-8243) + * Add more log info if readMeter is null (CASSANDRA-8238) + * add check of the system wall clock time at startup (CASSANDRA-8305) + * Support for frozen collections (CASSANDRA-7859) + * Fix overflow on histogram computation (CASSANDRA-8028) + * Have paxos reuse the timestamp generation of normal queries (CASSANDRA-7801) + * Fix incremental repair not remove parent session on remote (CASSANDRA-8291) + * Improve JBOD disk utilization (CASSANDRA-7386) + * Log failed host when preparing incremental repair (CASSANDRA-8228) +Merged from 2.0: + * Throw correct exception when trying to bind a keyspace or table +name (CASSANDRA-6952) * Make HHOM.compact synchronized (CASSANDRA-8416) * cancel latency-sampling task when CF is dropped (CASSANDRA-8401) * don't block SocketThread for MessagingService (CASSANDRA-8188) http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fa03413/src/java/org/apache/cassandra/cql3/Cql.g -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fa03413/test/unit/org/apache/cassandra/cql3/CQLTester.java -- diff --cc test/unit/org/apache/cassandra/cql3/CQLTester.java index dd22896,000..2226153 mode 100644,00..100644 --- a/test/unit/org/apache/cassandra/cql3/CQLTester.java +++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java @@@ -1,756 -1,0 +1,775 @@@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.cassandra.cql3; + +import java.io.File; +import java.nio.ByteBuffer; +import java.util.*; +import java.util.concurrent.CountDownLatch; +import java.util.concurrent.ExecutionException; +import java.util.concurrent.TimeUnit; +import java.util.concurrent.atomic.AtomicInteger; + +import com.google.common.base.Objects; +import com.google.common.collect.ImmutableSet; +import org.junit.AfterClass; +import org.junit.After; +import org.junit.Assert; +import org.junit.BeforeClass; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import org.apache.cassandra.SchemaLoader; +import org.apache.cassandra.concurrent.ScheduledExecutors; +import org.apache.cassandra.config.CFMetaData; +import org.apa
[2/2] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7fa03413 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7fa03413 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7fa03413 Branch: refs/heads/cassandra-2.1 Commit: 7fa034136a96aab4a8ca5173751bdb52bcbca500 Parents: c1610f6 71e1219 Author: Aleksey Yeschenko Authored: Tue Dec 9 13:59:18 2014 +0100 Committer: Aleksey Yeschenko Committed: Tue Dec 9 13:59:18 2014 +0100 -- CHANGES.txt | 2 ++ src/java/org/apache/cassandra/cql3/Cql.g| 1 + .../org/apache/cassandra/cql3/CQLTester.java| 25 +++-- .../apache/cassandra/cql3/UseStatementTest.java | 29 4 files changed, 54 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fa03413/CHANGES.txt -- diff --cc CHANGES.txt index b8d2ff6,7c89e60..28dd6b4 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,23 -1,6 +1,25 @@@ -2.0.12: +2.1.3 + * Reduce maxHintsInProgress (CASSANDRA-8415) + * BTree updates may call provided update function twice (CASSANDRA-8018) + * Release sstable references after anticompaction (CASSANDRA-8386) + * Handle abort() in SSTableRewriter properly (CASSANDRA-8320) + * Fix high size calculations for prepared statements (CASSANDRA-8231) + * Centralize shared executors (CASSANDRA-8055) + * Fix filtering for CONTAINS (KEY) relations on frozen collection + clustering columns when the query is restricted to a single + partition (CASSANDRA-8203) + * Do more aggressive entire-sstable TTL expiry checks (CASSANDRA-8243) + * Add more log info if readMeter is null (CASSANDRA-8238) + * add check of the system wall clock time at startup (CASSANDRA-8305) + * Support for frozen collections (CASSANDRA-7859) + * Fix overflow on histogram computation (CASSANDRA-8028) + * Have paxos reuse the timestamp generation of normal queries (CASSANDRA-7801) + * Fix incremental repair not remove parent session on remote (CASSANDRA-8291) + * Improve JBOD disk utilization (CASSANDRA-7386) + * Log failed host when preparing incremental repair (CASSANDRA-8228) +Merged from 2.0: + * Throw correct exception when trying to bind a keyspace or table +name (CASSANDRA-6952) * Make HHOM.compact synchronized (CASSANDRA-8416) * cancel latency-sampling task when CF is dropped (CASSANDRA-8401) * don't block SocketThread for MessagingService (CASSANDRA-8188) http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fa03413/src/java/org/apache/cassandra/cql3/Cql.g -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7fa03413/test/unit/org/apache/cassandra/cql3/CQLTester.java -- diff --cc test/unit/org/apache/cassandra/cql3/CQLTester.java index dd22896,000..2226153 mode 100644,00..100644 --- a/test/unit/org/apache/cassandra/cql3/CQLTester.java +++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java @@@ -1,756 -1,0 +1,775 @@@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.cassandra.cql3; + +import java.io.File; +import java.nio.ByteBuffer; +import java.util.*; +import java.util.concurrent.CountDownLatch; +import java.util.concurrent.ExecutionException; +import java.util.concurrent.TimeUnit; +import java.util.concurrent.atomic.AtomicInteger; + +import com.google.common.base.Objects; +import com.google.common.collect.ImmutableSet; +import org.junit.AfterClass; +import org.junit.After; +import org.junit.Assert; +import org.junit.BeforeClass; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import org.apache.cassandra.SchemaLoader; +import org.apache.cassandra.concurrent.ScheduledExecutors; +import org.apache.cassandra.config.CFMetaData; +import
[1/2] cassandra git commit: Throw correct exception when trying to bind a keyspace or table name
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 c1610f6da -> 7fa034136
Throw correct exception when trying to bind a keyspace or table name
patch by Benjamin Lerer; reviewed by Aleksey Yeschenko for
CASSANDRA-6952
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71e1219d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71e1219d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71e1219d
Branch: refs/heads/cassandra-2.1
Commit: 71e1219de71fe341316f8cab2f5faeea37ceff1e
Parents: c26a7e7
Author: Benjamin Lerer
Authored: Tue Dec 9 13:56:25 2014 +0100
Committer: Aleksey Yeschenko
Committed: Tue Dec 9 13:56:25 2014 +0100
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/cql3/Cql.g | 1 +
2 files changed, 3 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e1219d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5573316..7c89e60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.0.12:
+ * Throw correct exception when trying to bind a keyspace or table
+ name (CASSANDRA-6952)
* Make HHOM.compact synchronized (CASSANDRA-8416)
* cancel latency-sampling task when CF is dropped (CASSANDRA-8401)
* don't block SocketThread for MessagingService (CASSANDRA-8188)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e1219d/src/java/org/apache/cassandra/cql3/Cql.g
--
diff --git a/src/java/org/apache/cassandra/cql3/Cql.g
b/src/java/org/apache/cassandra/cql3/Cql.g
index 43b1c01..a80746c 100644
--- a/src/java/org/apache/cassandra/cql3/Cql.g
+++ b/src/java/org/apache/cassandra/cql3/Cql.g
@@ -771,6 +771,7 @@ cfOrKsName[CFName name, boolean isKs]
: t=IDENT { if (isKs) $name.setKeyspace($t.text, false); else
$name.setColumnFamily($t.text, false); }
| t=QUOTED_NAME{ if (isKs) $name.setKeyspace($t.text, true); else
$name.setColumnFamily($t.text, true); }
| k=unreserved_keyword { if (isKs) $name.setKeyspace(k, false); else
$name.setColumnFamily(k, false); }
+| QMARK {addRecognitionError("Bind variables cannot be used for keyspace
or table names");}
;
constant returns [Constants.Literal constant]
cassandra git commit: Throw correct exception when trying to bind a keyspace or table name
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 c26a7e767 -> 71e1219de
Throw correct exception when trying to bind a keyspace or table name
patch by Benjamin Lerer; reviewed by Aleksey Yeschenko for
CASSANDRA-6952
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71e1219d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71e1219d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71e1219d
Branch: refs/heads/cassandra-2.0
Commit: 71e1219de71fe341316f8cab2f5faeea37ceff1e
Parents: c26a7e7
Author: Benjamin Lerer
Authored: Tue Dec 9 13:56:25 2014 +0100
Committer: Aleksey Yeschenko
Committed: Tue Dec 9 13:56:25 2014 +0100
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/cql3/Cql.g | 1 +
2 files changed, 3 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e1219d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5573316..7c89e60 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.0.12:
+ * Throw correct exception when trying to bind a keyspace or table
+ name (CASSANDRA-6952)
* Make HHOM.compact synchronized (CASSANDRA-8416)
* cancel latency-sampling task when CF is dropped (CASSANDRA-8401)
* don't block SocketThread for MessagingService (CASSANDRA-8188)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e1219d/src/java/org/apache/cassandra/cql3/Cql.g
--
diff --git a/src/java/org/apache/cassandra/cql3/Cql.g
b/src/java/org/apache/cassandra/cql3/Cql.g
index 43b1c01..a80746c 100644
--- a/src/java/org/apache/cassandra/cql3/Cql.g
+++ b/src/java/org/apache/cassandra/cql3/Cql.g
@@ -771,6 +771,7 @@ cfOrKsName[CFName name, boolean isKs]
: t=IDENT { if (isKs) $name.setKeyspace($t.text, false); else
$name.setColumnFamily($t.text, false); }
| t=QUOTED_NAME{ if (isKs) $name.setKeyspace($t.text, true); else
$name.setColumnFamily($t.text, true); }
| k=unreserved_keyword { if (isKs) $name.setKeyspace(k, false); else
$name.setColumnFamily(k, false); }
+| QMARK {addRecognitionError("Bind variables cannot be used for keyspace
or table names");}
;
constant returns [Constants.Literal constant]
[jira] [Reopened] (CASSANDRA-8312) Use live sstables in snapshot repair if possible
[ https://issues.apache.org/jira/browse/CASSANDRA-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict reopened CASSANDRA-8312: - It looks to me like this doesn't tidy up after itself properly, at least on trunk. It opens an sstable from the snapshot if necessary, references it, and then releases only the reference it acquired - not the extra reference that would permit its BF etc. to be reclaimed. So this will likely leak significant amounts of memory. > Use live sstables in snapshot repair if possible > > > Key: CASSANDRA-8312 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8312 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12, 3.0, 2.1.3 > > Attachments: cassandra-2.0-8312-1.txt > > > Snapshot repair can be very much slower than parallel repairs because of the > overhead of opening the SSTables in the snapshot. This is particular true > when using LCS, as you typically have many smaller SSTables then. > I compared parallel and sequential repair on a small range on one of our > clusters (2*3 replicas). With parallel repair, this took 22 seconds. With > sequential repair (default in 2.0), the same range took 330 seconds! This is > an overhead of 330-22*6 = 198 seconds, just opening SSTables (there were > 1000+ sstables). Also, opening 1000 sstables for many smaller rangers surely > causes lots of memory churning. > The idea would be to list the sstables in the snapshot, but use the > corresponding sstables in the live set if it's still available. For almost > all sstables, the original one should still exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8346) Paxos operation can use stale data during multiple range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239355#comment-14239355
]
sankalp kohli commented on CASSANDRA-8346:
--
I don't think it is related as this JIRA is used when there is range movements.
> Paxos operation can use stale data during multiple range movements
> --
>
> Key: CASSANDRA-8346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8346
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments: 8346.txt
>
>
> Paxos operations correctly account for pending ranges for all operation
> pertaining to the Paxos state, but those pending ranges are not taken into
> account when reading the data to check for the conditions or during a serial
> read. It's thus possible to break the LWT guarantees by reading a stale
> value. This require 2 node movements (on the same token range) to be a
> problem though.
> Basically, we have {{RF}} replicas + {{P}} pending nodes. For the Paxos
> prepare/propose phases, the number of required participants (the "Paxos
> QUORUM") is {{(RF + P + 1) / 2}} ({{SP.getPaxosParticipants}}), but the read
> done to check conditions or for serial reads is done at a "normal" QUORUM (or
> LOCAL_QUORUM), and so a weaker {{(RF + 1) / 2}}. We have a problem if it's
> possible that said read can read only from nodes that were not part of the
> paxos participants, and so we have a problem if:
> {noformat}
> "normal quorum" == (RF + 1) / 2 <= (RF + P) - ((RF + P + 1) / 2) ==
> "participants considered - blocked for"
> {noformat}
> We're good if {{P = 0}} or {{P = 1}} since this inequality gives us
> respectively {{RF + 1 <= RF - 1}} and {{RF + 1 <= RF}}, both of which are
> impossible. But at {{P = 2}} (2 pending nodes), this inequality is equivalent
> to {{RF <= RF}} and so we might read stale data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8440) Refactor StorageProxy
[ https://issues.apache.org/jira/browse/CASSANDRA-8440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Szymaniuk updated CASSANDRA-8440: Assignee: (was: Marcin Szymaniuk) > Refactor StorageProxy > - > > Key: CASSANDRA-8440 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8440 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Joshua McKenzie > Fix For: 3.0 > > > The StorageProxy is currently a monolithic singleton with a collection of > static methods. This ticket will track a multi-phase effort to refactor this > into appropriate subclasses, convert the internals to asynchronous > operations, and eventually change the API to being async. > > See CASSANDRA-7392 for an example of a feature that this change would help > facilitate. > Broken down into 5 phases: > * Phase 1: Un-singleton and Break static methods down into classes > * Phase 2: Convert StorageProxy classes to futures, keep internal synchronous > processing so interface doesn't change > * Phase 3: Track count and limits on internal messages within StorageProxy > * Phase 4: Push async interface upstream > * Phase 5: Profile garbage generation from StorageProxy changes and consider > object pooling > Granularity with the breakdown above is to make reviews less painful and make > it easier to add unit-testing for this component as we go. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8440) Refactor StorageProxy
[ https://issues.apache.org/jira/browse/CASSANDRA-8440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Szymaniuk reassigned CASSANDRA-8440: --- Assignee: Marcin Szymaniuk > Refactor StorageProxy > - > > Key: CASSANDRA-8440 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8440 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Joshua McKenzie >Assignee: Marcin Szymaniuk > Fix For: 3.0 > > > The StorageProxy is currently a monolithic singleton with a collection of > static methods. This ticket will track a multi-phase effort to refactor this > into appropriate subclasses, convert the internals to asynchronous > operations, and eventually change the API to being async. > > See CASSANDRA-7392 for an example of a feature that this change would help > facilitate. > Broken down into 5 phases: > * Phase 1: Un-singleton and Break static methods down into classes > * Phase 2: Convert StorageProxy classes to futures, keep internal synchronous > processing so interface doesn't change > * Phase 3: Track count and limits on internal messages within StorageProxy > * Phase 4: Push async interface upstream > * Phase 5: Profile garbage generation from StorageProxy changes and consider > object pooling > Granularity with the breakdown above is to make reviews less painful and make > it easier to add unit-testing for this component as we go. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7873) Replace AbstractRowResolver.replies with collection with tailored properties
[
https://issues.apache.org/jira/browse/CASSANDRA-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237740#comment-14237740
]
Benedict edited comment on CASSANDRA-7873 at 12/9/14 11:43 AM:
---
mea culpa. thanks
+1
was (Author: benedict):
mea culpa. thanks
> Replace AbstractRowResolver.replies with collection with tailored properties
>
>
> Key: CASSANDRA-7873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7873
> Project: Cassandra
> Issue Type: Bug
> Environment: OSX and Ubuntu 14.04
>Reporter: Philip Thompson
>Assignee: Benedict
> Fix For: 3.0
>
> Attachments: 7873.21.txt, 7873.trunk.txt, 7873.txt, 7873_fixup.txt
>
>
> The dtest auth_test.py:TestAuth.system_auth_ks_is_alterable_test is failing
> on trunk only with the following stack trace:
> {code}
> Unexpected error in node1 node log:
> ERROR [Thrift:1] 2014-09-03 15:48:08,389 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.util.ConcurrentModificationException: null
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
> ~[na:1.7.0_65]
> at java.util.ArrayList$Itr.next(ArrayList.java:831) ~[na:1.7.0_65]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:71)
> ~[main/:na]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
> ~[main/:na]
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1228)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1154)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:256)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
> ~[main/:na]
> at org.apache.cassandra.auth.Auth.selectUser(Auth.java:257) ~[main/:na]
> at org.apache.cassandra.auth.Auth.isExistingUser(Auth.java:76)
> ~[main/:na]
> at org.apache.cassandra.service.ClientState.login(ClientState.java:178)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1486)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3579)
> ~[thrift/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3563)
> ~[thrift/:na]
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
> {code}
> That exception is thrown when the following query is sent:
> {code}
> """SELECT strategy_options
> FROM system.schema_keyspaces
> WHERE keyspace_name = 'system_auth'"""
> {code}
> The test alters the RF of the system_auth keyspace, then shuts down and
> restarts the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8414) Avoid loops over array backed iterators that call iter.remove()
[ https://issues.apache.org/jira/browse/CASSANDRA-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239312#comment-14239312 ] Benedict commented on CASSANDRA-8414: - We should integrate this for 2.1 also, since this behaviour is exhibited still, just not in compaction. In 2.1 we should use System.arraycopy and removed.nextSetBit though, as the performance will be improved, particularly for sparse removes. > Avoid loops over array backed iterators that call iter.remove() > --- > > Key: CASSANDRA-8414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8414 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Richard Low >Assignee: Jimmy Mårdell > Labels: performance > Fix For: 2.1.3 > > Attachments: cassandra-2.0-8414-1.txt > > > I noticed from sampling that sometimes compaction spends almost all of its > time in iter.remove() in ColumnFamilyStore.removeDeletedStandard. It turns > out that the cf object is using ArrayBackedSortedColumns, so deletes are from > an ArrayList. If the majority of your columns are GCable tombstones then this > is O(n^2). The data structure should be changed or a copy made to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6993) Windows: remove mmap'ed I/O for index files and force standard file access
[ https://issues.apache.org/jira/browse/CASSANDRA-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239307#comment-14239307 ] Benedict commented on CASSANDRA-6993: - Replacing isUnix() with !isWindows() is not functionally equivalent; this will capture Mac, Solaris, OpenBSD, FreeBSD and others as well, although in many situations this actually adequately captures what we want (such as for your specific change) it likely won't in all cases. As with CASSANRA-8038 this would benefit from sanitising our OS detection. Perhaps we could split this out into a minor ticket these both depend upon, as we have a bit of a mess right now that permits these sorts of logical mismatches to crop up. We should probably group POSIX compliant OSes together, and POSIX compliant file systems together, one of which is probably what we generally mean when we say isUnix(). > Windows: remove mmap'ed I/O for index files and force standard file access > -- > > Key: CASSANDRA-6993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6993 > Project: Cassandra > Issue Type: Improvement >Reporter: Joshua McKenzie >Assignee: Joshua McKenzie >Priority: Minor > Labels: Windows > Fix For: 3.0, 2.1.3 > > Attachments: 6993_2.1_v1.txt, 6993_v1.txt, 6993_v2.txt > > > Memory-mapped I/O on Windows causes issues with hard-links; we're unable to > delete hard-links to open files with memory-mapped segments even using nio. > We'll need to push for close to performance parity between mmap'ed I/O and > buffered going forward as the buffered / compressed path offers other > benefits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8308) Windows: Commitlog access violations on unit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239291#comment-14239291
]
Benedict commented on CASSANDRA-8308:
-
* channel.truncate() is not equivalent to raf.setLength(), and we want the
length to be set upfront to somewhat ensure contiguity
* would be nice to extract the "is linux" decision to an enum, embed it in
FBUtilities where we already have an isUnix() method (and an OPERATING_SYSTEM
property, that could be converted to the enum)
> Windows: Commitlog access violations on unit tests
> --
>
> Key: CASSANDRA-8308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8308
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Minor
> Labels: Windows
> Fix For: 3.0
>
> Attachments: 8308_v1.txt
>
>
> We have four unit tests failing on trunk on Windows, all with
> FileSystemException's related to the SchemaLoader:
> {noformat}
> [junit] Test
> org.apache.cassandra.db.compaction.DateTieredCompactionStrategyTest FAILED
> [junit] Test org.apache.cassandra.cql3.ThriftCompatibilityTest FAILED
> [junit] Test org.apache.cassandra.io.sstable.SSTableRewriterTest FAILED
> [junit] Test org.apache.cassandra.repair.LocalSyncTaskTest FAILED
> {noformat}
> Example error:
> {noformat}
> [junit] Caused by: java.nio.file.FileSystemException:
> build\test\cassandra\commitlog;0\CommitLog-5-1415908745965.log: The process
> cannot access the file because it is being used by another process.
> [junit]
> [junit] at
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> [junit] at
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> [junit] at
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> [junit] at
> sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> [junit] at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> [junit] at java.nio.file.Files.delete(Files.java:1079)
> [junit] at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8352) Timeout Exception on Node Failure in Remote Data Center
[ https://issues.apache.org/jira/browse/CASSANDRA-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239271#comment-14239271 ] Amit Singh Chowdhery commented on CASSANDRA-8352: - We have upgraded to Cassandra 2.0.11 and yet are facing the same trouble. Gist:- We have two 3 node clusters in two different DCs and if one or more of the nodes go down in one Data Center , ~5-10% traffic failure is observed on the other. CL: LOCAL_QUORUM RF=3 > Timeout Exception on Node Failure in Remote Data Center > --- > > Key: CASSANDRA-8352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8352 > Project: Cassandra > Issue Type: Bug > Environment: Unix, Cassandra 2.0.3 >Reporter: Akhtar Hussain > Labels: DataCenter, GEO-Red > > We have a Geo-red setup with 2 Data centers having 3 nodes each. When we > bring down a single Cassandra node down in DC2 by kill -9 , > reads fail on DC1 with TimedOutException for a brief amount of time (15-20 > sec~). > Questions: > 1.We need to understand why reads fail on DC1 when a node in another DC > i.e. DC2 fails? As we are using LOCAL_QUORUM for both reads/writes in DC1, > request should return once 2 nodes in local DC have replied instead of timing > out because of node in remote DC. > 2.We want to make sure that no Cassandra requests fail in case of node > failures. We used rapid read protection of ALWAYS/99percentile/10ms as > mentioned in > http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2. > But nothing worked. How to ensure zero request failures in case a node fails? > 3.What is the right way of handling HTimedOutException exceptions in > Hector? > 4.Please confirm are we using public private hostnames as expected? > We are using Cassandra 2.0.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8427) An error is written to System.out when UserTypesTest is run
[
https://issues.apache.org/jira/browse/CASSANDRA-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-8427:
--
Attachment: CASSANDRA-8427-trunk.txt
CASSANDRA-8427-2.1.txt
The problem was coming from the fact that {{CQLTester}} was trying to drop a
UDT that was used by another UDT.
The patch make sure that {{CQLTester}} drop the UDT, UDF and UDA in the reverse
order than the one in which they were created.
> An error is written to System.out when UserTypesTest is run
> ---
>
> Key: CASSANDRA-8427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8427
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Minor
> Attachments: CASSANDRA-8427-2.1.txt, CASSANDRA-8427-trunk.txt
>
>
> When running {{org.apache.cassandra.cql3.UserTypesTest}} the following error
> is printed out to the console.
> {code}ERROR 09:58:41 Fatal exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: Error setting schema
> for test (query was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:188)
> ~[classes/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> Caused by: java.lang.RuntimeException: Error setting schema for test (query
> was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:413)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester.access$3(CQLTester.java:404)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:167)
> ~[classes/:na]
> ... 7 common frames omitted
> Caused by: java.lang.RuntimeException: Error validating query DROP TYPE IF
> EXISTS cql_test_keyspace.type_2
> at
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:374)
> ~[main/:na]
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:409)
> ~[classes/:na]
> ... 9 common frames omitted
> Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Cannot
> drop user type cql_test_keyspace.type_2 as it is still used by user type
> type_3
> at
> org.apache.cassandra.cql3.statements.DropTypeStatement.validate(DropTypeStatement.java:93)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:361)
> ~[main/:na]
> ... 10 common frames omitted
> ERROR 09:58:41 Fatal exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.RuntimeException: java.lang.RuntimeException: Error setting schema
> for test (query was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:188)
> ~[classes/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> Caused by: java.lang.RuntimeException: Error setting schema for test (query
> was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:413)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester.access$3(CQLTester.java:404)
> ~[classes/:na]
> at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:167)
> ~[classes/:na]
> ... 7 common frames omitted
>
[jira] [Commented] (CASSANDRA-8421) Cassandra 2.1.1 UDT not returning value for LIST type as UDT
[
https://issues.apache.org/jira/browse/CASSANDRA-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239219#comment-14239219
]
madheswaran commented on CASSANDRA-8421:
h3. Another Issue in Search:
--
First Query searching list value {color:red} {key: 'contactNumber', value:
'89007'} {color}
{code:title=First Query |borderStyle=solid}
1) SELECT * from entity WHERE status_key < 3 and field_values contains {key:
'contactNumber', value: '89007'} and domain = 'pcs.com' allow filtering
;
entity_id| begining | domain | domain_type |
entity_template_name| field_values
|
global_entity_type | revision_time| status_key |
status_name | uuid
--+--+-+-+-+++--++-+--
723d4295-1ad2-4aba-8638-5bdd6b3be8b7 |1 | pcs.com |null |
DefaultPCSTemplate_User | [{key: 'access', value:
'[{"entityId":"c0e30978-9662-4d6e-9503-7fcfd4d7693c"},{"entityId":"9af1e1e2-05bd-4929-a2cc-ff9e6526992c"}]'},
{key: 'contactNumber', value: '89007'}, {key: 'firstName', value:
'James'}, {key: 'lastName', value: 'Smith'}, {key: 'primaryEmail', value:
'james9...@pcs.com'}, {key: 'roleName', value: 'admin'}, {key: 'userName',
value: 'James9007'}, {key: 'userType', value: 'some'}, {key: 'password', value:
'James9007'}] | USER | 5a0dad10-7edf-11e4-8d47-4b86331ee8c7 |
0 | ACTIVE | null
(1 rows)
{code}
2) Same query but searching another value of list {color:red} {key: 'access',
value:
'[{"entityId":"c0e30978-9662-4d6e-9503-7fcfd4d7693c"},{"entityId":"9af1e1e2-05bd-4929-a2cc-ff9e6526992c"}]'}
{color} from same *ROW* but it is not returning any value.
{code:title=SecondQuery |borderStyle=solid}
SELECT * from entity WHERE status_key < 3 and field_values contains {key:
'access', value:
'[{"entityId":"c0e30978-9662-4d6e-9503-7fcfd4d7693c"},{"entityId":"9af1e1e2-05bd-4929-a2cc-ff9e6526992c"}]'}
and domain = 'pcs.com' allow filtering ;
(0 rows)
{code}
Index Created for both status_key and field_values
{code}
CREATE INDEX entity_begining_idx_1 ON galaxy_development.entity (begining);
CREATE INDEX entity_domain_idx_1 ON galaxy_development.entity (domain);
CREATE INDEX entity_field_values_idx_1 ON galaxy_development.entity
(field_values);
CREATE INDEX entity_global_entity_type_idx_1 ON galaxy_development.entity
(global_entity_type);
CREATE INDEX entity_revision_time_idx_1 ON galaxy_development.entity
(revision_time);
CREATE INDEX entity_status_key_idx_1 ON galaxy_development.entity (status_key);
{code}
> Cassandra 2.1.1 UDT not returning value for LIST type as UDT
>
>
> Key: CASSANDRA-8421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8421
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Environment: single node cassandra
>Reporter: madheswaran
>Assignee: Sylvain Lebresne
> Fix For: 3.0, 2.1.3
>
> Attachments: 8421-unittest.txt, entity_data.csv
>
>
> I using List and its data type is UDT.
> UDT:
> {code}
> CREATE TYPE
> fieldmap (
> key text,
> value text
> );
> {code}
> TABLE:
> {code}
> CREATE TABLE entity (
> entity_id uuid PRIMARY KEY,
> begining int,
> domain text,
> domain_type text,
> entity_template_name text,
> field_values list,
> global_entity_type text,
> revision_time timeuuid,
> status_key int,
> status_name text,
> uuid timeuuid
> ) {code}
> INDEX:
> {code}
> CREATE INDEX entity_domain_idx_1 ON galaxy_dev.entity (domain);
> CREATE INDEX entity_field_values_idx_1 ON galaxy_dev.entity (field_values);
> CREATE INDEX entity_global_entity_type_idx_1 ON galaxy_dev.entity (gen_type );
> {code}
> QUERY
> {code}
> SELEC
[jira] [Commented] (CASSANDRA-8346) Paxos operation can use stale data during multiple range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239216#comment-14239216
]
Jochen Zeischka commented on CASSANDRA-8346:
Could issue 8446 be linked to this?
https://issues.apache.org/jira/browse/CASSANDRA-8446
Can we try the patch available for this issue (8346)?
> Paxos operation can use stale data during multiple range movements
> --
>
> Key: CASSANDRA-8346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8346
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments: 8346.txt
>
>
> Paxos operations correctly account for pending ranges for all operation
> pertaining to the Paxos state, but those pending ranges are not taken into
> account when reading the data to check for the conditions or during a serial
> read. It's thus possible to break the LWT guarantees by reading a stale
> value. This require 2 node movements (on the same token range) to be a
> problem though.
> Basically, we have {{RF}} replicas + {{P}} pending nodes. For the Paxos
> prepare/propose phases, the number of required participants (the "Paxos
> QUORUM") is {{(RF + P + 1) / 2}} ({{SP.getPaxosParticipants}}), but the read
> done to check conditions or for serial reads is done at a "normal" QUORUM (or
> LOCAL_QUORUM), and so a weaker {{(RF + 1) / 2}}. We have a problem if it's
> possible that said read can read only from nodes that were not part of the
> paxos participants, and so we have a problem if:
> {noformat}
> "normal quorum" == (RF + 1) / 2 <= (RF + P) - ((RF + P + 1) / 2) ==
> "participants considered - blocked for"
> {noformat}
> We're good if {{P = 0}} or {{P = 1}} since this inequality gives us
> respectively {{RF + 1 <= RF - 1}} and {{RF + 1 <= RF}}, both of which are
> impossible. But at {{P = 2}} (2 pending nodes), this inequality is equivalent
> to {{RF <= RF}} and so we might read stale data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8281) CQLSSTableWriter close does not work
[ https://issues.apache.org/jira/browse/CASSANDRA-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239214#comment-14239214 ] Benjamin Lerer commented on CASSANDRA-8281: --- [~yukim] is there something you want me to change? > CQLSSTableWriter close does not work > > > Key: CASSANDRA-8281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8281 > Project: Cassandra > Issue Type: Bug > Components: API > Environment: Cassandra 2.1.1 >Reporter: Xu Zhongxing >Assignee: Benjamin Lerer > Attachments: CASSANDRA-8281.txt > > > I called CQLSSTableWriter.close(). But the program still cannot exit. But the > same code works fine on Cassandra 2.0.10. > It seems that CQLSSTableWriter cannot be closed, and blocks the program from > exit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8446) Lost writes when using lightweight transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239213#comment-14239213 ] Jochen Zeischka commented on CASSANDRA-8446: Could this be linked to issue 8346? https://issues.apache.org/jira/browse/CASSANDRA-8346 > Lost writes when using lightweight transactions > --- > > Key: CASSANDRA-8446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8446 > Project: Cassandra > Issue Type: Bug > Components: API, Core > Environment: Cassandra 2.1.2 on Java(TM) SE Runtime Environment > (build 1.7.0_65-b17) >Reporter: Jochen Zeischka > > There's a serious problem when using lightweight transactions. Whenever th > cluster gets any load, write timeout exceptions start to occur and the client > has no way to know whether the write actually succeeded or not. > I a simple test (https://gist.github.com/anonymous/4c83f2962b57fce4c3df) this > results in large percentages of lost writes (0 - 50%, depending on the load). > The problem was described in > https://stackoverflow.com/questions/27313360/how-can-we-avoid-losing-writes-when-using-lightweight-transactions-cas-in-cass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8397) Support UPDATE with IN requirement for clustering key
[
https://issues.apache.org/jira/browse/CASSANDRA-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239211#comment-14239211
]
Jens Rantil commented on CASSANDRA-8397:
> My plan is to reuse the restriction code of SelectStatement for update and
> delete statements. If it works well it would make it easy to support for
> delete and update all the possible restriction cases that are currently
> supported by the select.
Just curious, performancewise, would a multi-update require a single commitlog
item or multiple commitlog items?
> Support UPDATE with IN requirement for clustering key
> -
>
> Key: CASSANDRA-8397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8397
> Project: Cassandra
> Issue Type: Wish
>Reporter: Jens Rantil
>Assignee: Benjamin Lerer
>Priority: Minor
>
> {noformat}
> CREATE TABLE events (
> userid uuid,
> id timeuuid,
> content text,
> type text,
> PRIMARY KEY (userid, id)
> )
> # Add data
> cqlsh:mykeyspace> UPDATE events SET content='Hello' WHERE
> userid=57b47f85-56c4-4968-83cf-4c4e533944e9 AND id IN
> (046e9da0-7945-11e4-a76f-770773bbbf7e, 046e0160-7945-11e4-a76f-770773bbbf7e);
> code=2200 [Invalid query] message="Invalid operator IN for PRIMARY KEY part
> id"
> {noformat}
> I was surprised this doesn't work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8446) Lost writes when using lightweight transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239206#comment-14239206 ] Jochen Zeischka commented on CASSANDRA-8446: Might be interesting: we do not get write timeouts when using replication factor 2, but do get them with rep factor 3. > Lost writes when using lightweight transactions > --- > > Key: CASSANDRA-8446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8446 > Project: Cassandra > Issue Type: Bug > Components: API, Core > Environment: Cassandra 2.1.2 on Java(TM) SE Runtime Environment > (build 1.7.0_65-b17) >Reporter: Jochen Zeischka > > There's a serious problem when using lightweight transactions. Whenever th > cluster gets any load, write timeout exceptions start to occur and the client > has no way to know whether the write actually succeeded or not. > I a simple test (https://gist.github.com/anonymous/4c83f2962b57fce4c3df) this > results in large percentages of lost writes (0 - 50%, depending on the load). > The problem was described in > https://stackoverflow.com/questions/27313360/how-can-we-avoid-losing-writes-when-using-lightweight-transactions-cas-in-cass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239198#comment-14239198
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-7124:
-
I am planning to create separate patches for separate tasks such as compact,
decommission etc. Hope that is fine.
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: 7124-wip.txt, cassandra-trunk-compact-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8397) Support UPDATE with IN requirement for clustering key
[
https://issues.apache.org/jira/browse/CASSANDRA-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239193#comment-14239193
]
Benjamin Lerer commented on CASSANDRA-8397:
---
My plan is to reuse the restriction code of {{SelectStatement}} for update and
delete statements. If it works well it would make it easy to support for delete
and update all the possible restriction cases that are currently supported by
the select.
> Support UPDATE with IN requirement for clustering key
> -
>
> Key: CASSANDRA-8397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8397
> Project: Cassandra
> Issue Type: Wish
>Reporter: Jens Rantil
>Assignee: Benjamin Lerer
>Priority: Minor
>
> {noformat}
> CREATE TABLE events (
> userid uuid,
> id timeuuid,
> content text,
> type text,
> PRIMARY KEY (userid, id)
> )
> # Add data
> cqlsh:mykeyspace> UPDATE events SET content='Hello' WHERE
> userid=57b47f85-56c4-4968-83cf-4c4e533944e9 AND id IN
> (046e9da0-7945-11e4-a76f-770773bbbf7e, 046e0160-7945-11e4-a76f-770773bbbf7e);
> code=2200 [Invalid query] message="Invalid operator IN for PRIMARY KEY part
> id"
> {noformat}
> I was surprised this doesn't work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8446) Lost writes when using lightweight transactions
Jochen Zeischka created CASSANDRA-8446: -- Summary: Lost writes when using lightweight transactions Key: CASSANDRA-8446 URL: https://issues.apache.org/jira/browse/CASSANDRA-8446 Project: Cassandra Issue Type: Bug Components: API, Core Environment: Cassandra 2.1.2 on Java(TM) SE Runtime Environment (build 1.7.0_65-b17) Reporter: Jochen Zeischka There's a serious problem when using lightweight transactions. Whenever th cluster gets any load, write timeout exceptions start to occur and the client has no way to know whether the write actually succeeded or not. I a simple test (https://gist.github.com/anonymous/4c83f2962b57fce4c3df) this results in large percentages of lost writes (0 - 50%, depending on the load). The problem was described in https://stackoverflow.com/questions/27313360/how-can-we-avoid-losing-writes-when-using-lightweight-transactions-cas-in-cass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[Cassandra Wiki] Update of "ClientOptions" by achilleasa
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "ClientOptions" page has been changed by achilleasa: https://wiki.apache.org/cassandra/ClientOptions?action=diff&rev1=191&rev2=192 Comment: Added cassandra driver for Dart * [[https://github.com/eklavya/Scqla|Scqla]] * Lua * [[https://github.com/jbochi/lua-resty-cassandra|lua-resty-cassandra]] + * Dart + * [[https://github.com/achilleasa/dart_cassandra_cql|dart_cassandra_cql]] = Thrift = For older Thrift clients, see ClientOptionsThrift.
