[jira] [Commented] (CASSANDRA-12151) Audit logging for database activity

2018-05-11 Thread Stefan Podkowinski (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472417#comment-16472417
 ] 

Stefan Podkowinski commented on CASSANDRA-12151:


Pushed a commit at a6bf9c53531 to let users know that they can't expect any 
prepared statement values in the logs. Thanks for your contribution, 
[~vinaykumarcse].

> Audit logging for database activity
> ---
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: stefan setyadi
>Assignee: Vinay Chella
>Priority: Major
> Fix For: 4.0
>
> Attachments: 12151.txt, CASSANDRA_12151-benchmark.html, 
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done 
> on our server.
> It should show username, remote address, timestamp, action type, keyspace, 
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the 
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every 
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting 
> a specific keyspace and column family.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



cassandra git commit: Docs: add audit logging limitations

2018-05-11 Thread spod
Repository: cassandra
Updated Branches:
  refs/heads/trunk f56871b88 -> a6bf9c535


Docs: add audit logging limitations


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a6bf9c53
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a6bf9c53
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a6bf9c53

Branch: refs/heads/trunk
Commit: a6bf9c535310c91a72648f08572db8574250eb6f
Parents: f56871b
Author: Stefan Podkowinski 
Authored: Fri May 11 20:15:19 2018 +0200
Committer: Stefan Podkowinski 
Committed: Fri May 11 20:15:19 2018 +0200

--
 doc/source/operating/audit_logging.rst | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a6bf9c53/doc/source/operating/audit_logging.rst
--
diff --git a/doc/source/operating/audit_logging.rst 
b/doc/source/operating/audit_logging.rst
index 9be7a43..b073f1a 100644
--- a/doc/source/operating/audit_logging.rst
+++ b/doc/source/operating/audit_logging.rst
@@ -39,6 +39,11 @@ Audit logging captures following events
 
 - All database commands executed via Native protocol (CQL) attempted or 
successfully executed.
 
+Limitations
+^^^
+
+Executing prepared statements will log the query as provided by the client in 
the prepare call, along with the execution time stamp and all other attributes 
(see below). Actual values bound for prepared statement execution will not show 
up in the audit log.
+
 What does it log
 ^^^
 Each audit log implementation has access to the following attributes, and for 
the default text based logger these fields are concatenated with `|` s to yield 
the final message.
@@ -70,7 +75,7 @@ cassandra.yaml configurations for AuditLog
- ``included_users``: Comma separated list of users to be included in 
audit log, default - includes all users
- ``excluded_users``: Comma separated list of users to be excluded from 
audit log, default - excludes no user
 
- 
+
 List of available categories are: QUERY, DML, DDL, DCL, OTHER, AUTH, ERROR, 
PREPARE
 
 NodeTool command to enable AuditLog


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-14444) Got NPE when querying Cassandra 3.11.2

2018-05-11 Thread Xiaodong Xie (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472375#comment-16472375
 ] 

Xiaodong Xie commented on CASSANDRA-1:
--

Here is my PR: [https://github.com/apache/cassandra/pull/225]

Could anyone please have a look? Thanks a lot. 

> Got NPE when querying Cassandra 3.11.2
> --
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Ubuntu 14.04, JDK 1.8.0_171. 
> Cassandra 3.11.2
>Reporter: Xiaodong Xie
>Priority: Major
>
> We just upgraded our Cassandra cluster from 2.2.6 to 3.11.2
> After upgrading, we immediately got exceptions in Cassandra like this one: 
>  
> ERROR [Native-Transport-Requests-1] 2018-05-11 17:10:21,994 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.dht.RandomPartitioner.getToken(RandomPartitioner.java:248)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.dht.RandomPartitioner.decorateKey(RandomPartitioner.java:92)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.config.CFMetaData.decorateKey(CFMetaData.java:666) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.service.pager.PartitionRangeQueryPager.(PartitionRangeQueryPager.java:44)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.db.PartitionRangeReadCommand.getPager(PartitionRangeReadCommand.java:268)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.getPager(SelectStatement.java:475)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:288)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:255) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:240) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.2.jar:3.11.2]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_171]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.2.jar:3.11.2]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_171]
>  
> The table schema is like:
> CREATE TABLE example.example_table (
>  id bigint,
>  hash text,
>  json text,
>  PRIMARY KEY (id, hash)
> ) WITH COMPACT STORAGE
>  
> The query is something like:
> "select * from example.example_table;" // (We do know this is bad practise, 
> and we are trying to fix that right now)
> with fetch-size as 200, using DataStax Java driver. 
> This table contains about 20k rows. 
>  
> Actually, the fix is quite simple, 
>  
> --- a/src/java/org/apache/cassandra/service/pager/PagingState.java
> +++ b/src/java/org/apache/cassandra/service/pager/PagingState.java
> @@ -46,7 +46,7 @@ public class PagingState
> public PagingState(ByteBuffer partitionKey, RowMark rowMark, int remaining, 
> int remainingInPartition)
>  {
> - this.partitionKey = partitionKey;
> + this.partitionKey = partitionKey == null ? ByteBufferUtil.EMPTY_BYTE_BUFFER 
> : partitionKey;
>  this.rowMark = rowMark;
>  this.remaining = remaining;
>  this.remainingInPartition = remainingInPartition;
>  
> "partitionKey == null 

[jira] [Commented] (CASSANDRA-14444) Got NPE when querying Cassandra 3.11.2

2018-05-11 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472373#comment-16472373
 ] 

ASF GitHub Bot commented on CASSANDRA-1:


GitHub user xiaodong-xie opened a pull request:

https://github.com/apache/cassandra/pull/225

Fix NPE, CASSANDRA-1

The detail was mentioned in: 
https://issues.apache.org/jira/browse/CASSANDRA-1

Thanks a lot. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/xiaodong-xie/cassandra fix-NPE

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/225.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #225


commit eb36aadad44c8374f7c2dabe0bc989976d9025a8
Author: Xiaodong Xie 
Date:   2018-05-11T17:57:16Z

Fix NPE, CASSANDRA-1




> Got NPE when querying Cassandra 3.11.2
> --
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Ubuntu 14.04, JDK 1.8.0_171. 
> Cassandra 3.11.2
>Reporter: Xiaodong Xie
>Priority: Major
>
> We just upgraded our Cassandra cluster from 2.2.6 to 3.11.2
> After upgrading, we immediately got exceptions in Cassandra like this one: 
>  
> ERROR [Native-Transport-Requests-1] 2018-05-11 17:10:21,994 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.dht.RandomPartitioner.getToken(RandomPartitioner.java:248)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.dht.RandomPartitioner.decorateKey(RandomPartitioner.java:92)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.config.CFMetaData.decorateKey(CFMetaData.java:666) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.service.pager.PartitionRangeQueryPager.(PartitionRangeQueryPager.java:44)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.db.PartitionRangeReadCommand.getPager(PartitionRangeReadCommand.java:268)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.getPager(SelectStatement.java:475)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:288)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:255) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:240) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.11.2.jar:3.11.2]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.2.jar:3.11.2]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_171]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.2.jar:3.11.2]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_171]
>  
> The table schema is like:
> CREATE TABLE example.example_table (
>  id bigint,
>  hash text,
>  json text,
>  PRIMARY KEY (id, hash)
> ) WITH COMPACT STORAGE
>  
> The query is something like:
> "select * from example.example_table;" // (We do know this is bad practise, 
> and we are trying to fix that right now)
> 

[jira] [Created] (CASSANDRA-14444) Got NPE when querying Cassandra 3.11.2

2018-05-11 Thread Xiaodong Xie (JIRA)
Xiaodong Xie created CASSANDRA-1:


 Summary: Got NPE when querying Cassandra 3.11.2
 Key: CASSANDRA-1
 URL: https://issues.apache.org/jira/browse/CASSANDRA-1
 Project: Cassandra
  Issue Type: Bug
  Components: CQL
 Environment: Ubuntu 14.04, JDK 1.8.0_171. 

Cassandra 3.11.2
Reporter: Xiaodong Xie


We just upgraded our Cassandra cluster from 2.2.6 to 3.11.2

After upgrading, we immediately got exceptions in Cassandra like this one: 

 

ERROR [Native-Transport-Requests-1] 2018-05-11 17:10:21,994 
QueryMessage.java:129 - Unexpected error during query
java.lang.NullPointerException: null
at 
org.apache.cassandra.dht.RandomPartitioner.getToken(RandomPartitioner.java:248) 
~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.dht.RandomPartitioner.decorateKey(RandomPartitioner.java:92)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at org.apache.cassandra.config.CFMetaData.decorateKey(CFMetaData.java:666) 
~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.service.pager.PartitionRangeQueryPager.(PartitionRangeQueryPager.java:44)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.db.PartitionRangeReadCommand.getPager(PartitionRangeReadCommand.java:268)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.cql3.statements.SelectStatement.getPager(SelectStatement.java:475)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:288)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:255) 
~[apache-cassandra-3.11.2.jar:3.11.2]
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:240) 
~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
 [apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
 [apache-cassandra-3.11.2.jar:3.11.2]
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [netty-all-4.0.44.Final.jar:4.0.44.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
 [netty-all-4.0.44.Final.jar:4.0.44.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
 [netty-all-4.0.44.Final.jar:4.0.44.Final]
at 
io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
 [netty-all-4.0.44.Final.jar:4.0.44.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_171]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
 [apache-cassandra-3.11.2.jar:3.11.2]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
[apache-cassandra-3.11.2.jar:3.11.2]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_171]

 

The table schema is like:

CREATE TABLE example.example_table (
 id bigint,
 hash text,
 json text,
 PRIMARY KEY (id, hash)
) WITH COMPACT STORAGE

 

The query is something like:

"select * from example.example_table;" // (We do know this is bad practise, and 
we are trying to fix that right now)

with fetch-size as 200, using DataStax Java driver. 

This table contains about 20k rows. 

 

Actually, the fix is quite simple, 

 

--- a/src/java/org/apache/cassandra/service/pager/PagingState.java
+++ b/src/java/org/apache/cassandra/service/pager/PagingState.java
@@ -46,7 +46,7 @@ public class PagingState

public PagingState(ByteBuffer partitionKey, RowMark rowMark, int remaining, int 
remainingInPartition)
 {
- this.partitionKey = partitionKey;
+ this.partitionKey = partitionKey == null ? ByteBufferUtil.EMPTY_BYTE_BUFFER : 
partitionKey;
 this.rowMark = rowMark;
 this.remaining = remaining;
 this.remainingInPartition = remainingInPartition;

 

"partitionKey == null ? ByteBufferUtil.EMPTY_BYTE_BUFFER : partitionKey;" is in 
2.2.6 and 2.2.8. But it was removed for some reason. 

The interesting part is that, we have: 

public final ByteBuffer partitionKey; // Can be null for single partition 
queries.

It seems "partitionKey" could be null.

Thanks a lot. 

 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional 

[jira] [Updated] (CASSANDRA-6893) Unintended update with conditional statement

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6893:

Labels: LWT qa-resolved  (was: qa-resolved)

> Unintended update with conditional statement
> 
>
> Key: CASSANDRA-6893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6893
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu Precise 64bit / Cassandra 2.0.6
>Reporter: Suguru Namura
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT, qa-resolved
> Fix For: 2.0.7
>
> Attachments: 6893.txt, ConcurrentCASUpdate.java
>
>
> After updated to 2.0.6, I have encountered the strange behavior of 
> conditional updates.
> When I executed CQL like UPDATE test SET value = ? WHERE id = ? IF value = ? 
> in concurrent, sometimes cassandra returns true even if value is not 
> satisfied the condition.
> I have attached the program which reproduce this issue. The program works 
> fine in cassandra 2.0.5. But it seems that resets values while execution in 
> 2.0.6.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5830) Paxos loops endlessly due to faulty condition check

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5830:

Labels: LWT paxos  (was: paxos)

> Paxos loops endlessly due to faulty condition check
> ---
>
> Key: CASSANDRA-5830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5830
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 2.0 beta 2
>Reporter: Soumava Ghosh
>Assignee: Soumava Ghosh
>Priority: Major
>  Labels: LWT, paxos
> Fix For: 2.0.0
>
>
> Following is the code segment (StorageProxy.java:361) which causes the issue: 
> Start is the start time of the paxos, is always less than the current system 
> time, and therefore the negative difference is always less than the timeout. 
> {code:title=StorageProxy.java|borderStyle=solid}
> private static UUID beginAndRepairPaxos(long start, ByteBuffer key, 
> CFMetaData metadata, List liveEndpoints, int 
> requiredParticipants, ConsistencyLevel consistencyForPaxos)
> throws WriteTimeoutException
> {
> long timeout = 
> TimeUnit.MILLISECONDS.toNanos(DatabaseDescriptor.getCasContentionTimeout());
> PrepareCallback summary = null;
> while (start - System.nanoTime() < timeout)
> {
> long ballotMillis = summary == null
>   ? System.currentTimeMillis()
>   : Math.max(System.currentTimeMillis(), 1 + 
> UUIDGen.unixTimestamp(summary.inProgressCommit.ballot));
> UUID ballot = UUIDGen.getTimeUUID(ballotMillis);
> {code}
> Here, the paxos gets stuck when PREPARE returns 'true' but with 
> inProgressCommit. The code in StorageProxy.java:beginAndRepairPaxos() then 
> tries to issue a PROPOSE and COMMIT for the inProgressCommit, and if it 
> repeatedly receives 'false' as a PREPARE_RESPONSE it gets stuck in an endless 
> loop until PREPARE_RESPONSE is true. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-10786:
-
Labels: LWT client-impacting doc-impacting protocolv5  (was: 
client-impacting doc-impacting protocolv5)

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: LWT, client-impacting, doc-impacting, protocolv5
> Fix For: 4.0
>
>
> {color:red}
> Warning for implementors: the spec has a typo, see CASSANDRA-13986
> {color}
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result 
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to 
> the prepared statement id. If it doesn't match the current one on the server, 
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new 
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated 
> result metadata (this overrides the {{No_metadata}} flag, even if the client 
> had requested it)
> - the client updates its copy of the result metadata before it decodes the 
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and 
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry, 
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456) 
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false, 
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute 
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8754) Required consistency level

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-8754:

Labels: LWT ponies  (was: ponies)

> Required consistency level
> --
>
> Key: CASSANDRA-8754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8754
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Ryan Svihla
>Priority: Major
>  Labels: LWT, ponies
>
> Idea is to prevent a query based on a consistency level not being met. For 
> example we can specify that all queries should be at least CL LOCAL_QUORUM.
> Lots of users struggle with getting all their dev teams on board with 
> consistency levels and all the ramifications. The normal solution for this 
> has traditionally to build a service in front of Cassandra that the entire 
> dev team accesses. However, this has proven challenging for some 
> organizations to do correctly, and I think an easier approach would be to 
> require a given consistency level as a matter of enforced policy in the 
> database. 
> I'm open for where this belongs. The most flexible approach is at a table 
> level, however I'm concerned this is potentially error prone and labor 
> intensive. It could be a table attribute similar to compaction strategy.
> The simplest administratively is a cluster level, in say the cassandra.yaml
> The middle ground is at they keyspace level, the only downside I could 
> foresee is keyspace explosion to fit involved minimum schemes. It could be a 
> keyspace attribute such as replication strategy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-9361) Add all possible consistency levels to Cassandra-Stress and make LOCAL_ONE the default one

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9361:

Labels: LWT stress  (was: stress)

> Add all possible consistency levels to Cassandra-Stress and make LOCAL_ONE 
> the default one
> --
>
> Key: CASSANDRA-9361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9361
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Mario Lazaro
>Assignee: Mario Lazaro
>Priority: Minor
>  Labels: LWT, stress
> Fix For: 2.1.6
>
> Attachments: patch.txt
>
>
> CASSANDRA-8253 added all of them but CASSANDRA-8769 delete some of them from 
> CommandSettings.java
> Also notice the default consistency is set to ONE, I believe it'd be better 
> if we use LOCAL_ONE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-9007) Run stress nightly against trunk in a way that validates

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9007:

Labels: LWT monthly-release  (was: monthly-release)

> Run stress nightly against trunk in a way that validates
> 
>
> Key: CASSANDRA-9007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9007
> Project: Cassandra
>  Issue Type: Task
>Reporter: Ariel Weisberg
>Assignee: Philip Thompson
>Priority: Major
>  Labels: LWT, monthly-release
>
> Stress has some very basic validation functionality when used without 
> workload profiles. It found a bug on trunk when I first ran it so it has 
> value even though the validation is basic.
> As a beachhead for the kind of blackbox validation that we are missing we can 
> start by running stress nightly or 24/7 in some rotation.
> There should be two jobs. One job has inverted success criteria (C* should 
> lose some data) and the job should only "pass" if the failure is detected. 
> This is just to prove that the harness reports failure if failure occurs.
> Another would be the real job that runs stress, parses and parses the output 
> for reports of missing data.
> This job is the first pass and basis of what we can point to when a developer 
> makes a change, implements a feature, or fixes a bug, and say "go add 
> validation to this job."
> Follow on tickets to link to this
> * Test multiple configurations
> * Get stress to validate more query functionality and APIs (counters, LWT, 
> batches)
> * Parse logs and fail tests on error level logs (great way to improve log 
> messages over time)
> * ?
> I am going to hold off on creating a ton of issues until we have a basic 
> version of the job running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8986) Major cassandra-stress refactor

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-8986:

Labels: LWT stress  (was: stress)

> Major cassandra-stress refactor
> ---
>
> Key: CASSANDRA-8986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8986
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Benedict
>Priority: Major
>  Labels: LWT, stress
>
> We need a tool for both stressing _and_ validating more complex workloads 
> than stress currently supports. Stress needs a raft of changes, and I think 
> it would be easier to deliver many of these as a single major endeavour which 
> I think is justifiable given its audience. The rough behaviours I want stress 
> to support are:
> * Ability to know exactly how many rows it will produce, for any clustering 
> prefix, without generating those prefixes
> * Ability to generate an amount of data proportional to the amount it will 
> produce to the server (or consume from the server), rather than proportional 
> to the variation in clustering columns
> * Ability to reliably produce near identical behaviour each run
> * Ability to understand complex overlays of operation types (LWT, Delete, 
> Expiry, although perhaps not all implemented immediately, the framework for 
> supporting them easily)
> * Ability to (with minimal internal state) understand the complete cluster 
> state through overlays of multiple procedural generations
> * Ability to understand the in-flight state of in-progress operations (i.e. 
> if we're applying a delete, understand that the delete may have been applied, 
> and may not have been, for potentially multiple conflicting in flight 
> operations)
> I think the necessary changes to support this would give us the _functional_ 
> base to support all the functionality I can currently envisage stress 
> needing. Before embarking on this (which I may attempt very soon), it would 
> be helpful to get input from others as to features missing from stress that I 
> haven't covered here that we will certainly want in the future, so that they 
> can be factored in to the overall design and hopefully avoid another refactor 
> one year from now, as its complexity is scaling each time, and each time it 
> is a higher sunk cost. [~jbellis] [~iamaleksey] [~slebresne] [~tjake] 
> [~enigmacurry] [~aweisberg] [~blambov] [~jshook] ... and @everyone else :) 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7960) Add stress profile yaml with LWT

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7960:

Labels: LWT stress  (was: stress)

> Add stress profile yaml with LWT
> 
>
> Key: CASSANDRA-7960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7960
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: LWT, stress
> Fix For: 4.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-11003) cqlsh: LWT operations not handled correctly in 3.0+

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-11003:
-
Labels: LWT cqlsh  (was: cqlsh)

> cqlsh: LWT operations not handled correctly in 3.0+
> ---
>
> Key: CASSANDRA-11003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11003
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Eduard Tudenhoefner
>Assignee: Eduard Tudenhoefner
>Priority: Major
>  Labels: LWT, cqlsh
> Fix For: 3.0.3, 3.3
>
> Attachments: 11003-cassandra-3.0.txt
>
>
> {code}
> $ cqlsh -u cassandra -p cassandra
> Connected to abc at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.1.816 | DSE 5.0.0 | CQL spec 3.4.0 | Native 
> protocol v4]
> Use HELP for help.
> cassandra@cqlsh> SOME COMMAND;
> Shell instance has no attribute 'parse_for_table_meta'
> {code}
> I think this is happening because of a bad merge 
> (https://github.com/apache/cassandra/commit/2800bf1082e773daf0af29516b61c711acda626b#diff-1cce67f7d76864f07aaf4d986d6fc051).
>  We just need to rename *parse_for_update_meta* to *parse_for_table_meta*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12690) LWT: Inserting Subset of columns returns all columns

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-12690:
-
Labels: LWT transaction transactions  (was: transaction transactions)

> LWT: Inserting Subset of columns returns all columns
> 
>
> Key: CASSANDRA-12690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12690
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: 3.x
>Reporter: Highstead
>Priority: Minor
>  Labels: LWT, transaction, transactions
>
> See: https://github.com/gocql/gocql/issues/792#issuecomment-248983669
> When inserting a subset of the table columns with the use of light weight 
> transactions the cassandra result returns a full set of unordered cassandra 
> column values.  
> SETUP:
> ```
> CREATE TABLE IF NOT EXISTS test.inserttest(
> key bigint,
> session_token text,
> foo text, 
> bar text,
> PRIMARY KEY(key, event_date, session_token);
> INSERT INTO test.inserttest(key, session_token, foo) VALUES (1, 'myToken', 
> 'baz') IF NOT EXISTS;
> ```
> `insert into test.inserttest(key, session_token, foo) VALUES (1, 'myToken', 
> 'bez') IF NOT EXISTS;`
> Expected result: Returns False, 1, myToken, baz
> Actual result: Returns true and all column values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12691) LWT: Inserting Subset of columns returns all columns

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-12691:
-
Labels: LWT transaction transactions  (was: transaction transactions)

> LWT: Inserting Subset of columns returns all columns
> 
>
> Key: CASSANDRA-12691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12691
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: 3.x
>Reporter: Highstead
>Priority: Minor
>  Labels: LWT, transaction, transactions
>
> See: https://github.com/gocql/gocql/issues/792#issuecomment-248983669
> When inserting a subset of the table columns with the use of light weight 
> transactions the cassandra result returns a full set of unordered cassandra 
> column values.  
> SETUP:
> {code}
> CREATE TABLE IF NOT EXISTS test.inserttest(
> key bigint,
> session_token text,
> foo text, 
> bar text,
> PRIMARY KEY(key, event_date, session_token);
> INSERT INTO test.inserttest(key, session_token, foo) VALUES (1, 'myToken', 
> 'baz') IF NOT EXISTS;
> {code}
> {code}insert into test.inserttest(key, session_token, foo) VALUES (1, 
> 'myToken', 'bez') IF NOT EXISTS;{code}
> Expected result: Returns False, 1, myToken, baz
> Actual result: Returns true and all column values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7423) Allow updating individual subfields of UDT

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7423:

Labels: LWT client-impacting cql docs-impacting  (was: client-impacting cql 
docs-impacting)

> Allow updating individual subfields of UDT
> --
>
> Key: CASSANDRA-7423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Tyler Hobbs
>Priority: Major
>  Labels: LWT, client-impacting, cql, docs-impacting
> Fix For: 3.6
>
>
> Since user defined types were implemented in CASSANDRA-5590 as blobs (you 
> have to rewrite the entire type in order to make any modifications), they 
> can't be safely used without LWT for any operation that wants to modify a 
> subset of the UDT's fields by any client process that is not authoritative 
> for the entire blob. 
> When trying to use UDTs to model complex records (particularly with nesting), 
> this is not an exceptional circumstance, this is the totally expected normal 
> situation. 
> The use of UDTs for anything non-trivial is harmful to either performance or 
> consistency or both.
> edit: to clarify, i believe that most potential uses of UDTs should be 
> considered anti-patterns until/unless we have field-level r/w access to 
> individual elements of the UDT, with individual timestamps and standard LWW 
> semantics



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13925) Add SERIAL and LOCAL_SERIAL support for cassandra-stress

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13925:
-
Labels: LWT tools  (was: tools)

> Add SERIAL and LOCAL_SERIAL support for cassandra-stress
> 
>
> Key: CASSANDRA-13925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13925
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: LWT, tools
> Fix For: 4.0
>
>
> Follow-up for {{CASSANDRA-7960: Add stress profile yaml with LWT}}
> As {{cassandra-stress}} supports LWT, but cannot set CL to SERIAL.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13529) cassandra-stress light-weight transaction support

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13529:
-
Labels: LWT  (was: )

> cassandra-stress light-weight transaction support
> -
>
> Key: CASSANDRA-13529
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13529
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Stress
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Minor
>  Labels: LWT
> Fix For: 4.x
>
> Attachments: 13529.txt, lwttest.yaml
>
>
> It would be nice to have a light-weight transaction support in 
> cassandra-stress.
> Although currently in cassandra-stress we can achieve light-weight 
> transaction partially by using static conditions like "IF col1 != null" or 
> "IF not EXIST". 
> If would be ideal to have full fledged light-weight transaction support like 
> "IF col1 = ? and col2 = ?". One way to implement is to read values from 
> Cassandra and use that in the condition so it will execute all the paxos 
> phases in Cassandra.
> Please find git link for the patch: 
> https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:13529-trunk?expand=1
> ||trunk|
> |[branch|https://github.com/jaydeepkumar1984/cassandra/tree/13529-trunk]|
> |[utests|https://circleci.com/gh/jaydeepkumar1984/cassandra/8]|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5441) Add support for read at CL.SERIAL

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5441:

Labels: LWT  (was: )

> Add support for read at CL.SERIAL
> -
>
> Key: CASSANDRA-5441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5441
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Affects Versions: 2.0 beta 1
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Major
>  Labels: LWT
> Fix For: 2.0 beta 1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6246) EPaxos

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6246:

Labels: LWT messaging-service-bump-required  (was: 
messaging-service-bump-required)

> EPaxos
> --
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Blake Eggleston
>Priority: Major
>  Labels: LWT, messaging-service-bump-required
> Fix For: 4.x
>
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is 
> that Multi-paxos requires leader election and hence, a period of 
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
> (2) is particularly useful across multiple datacenters, and (3) allows any 
> node to act as coordinator: 
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to 
> implement it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6069) Sets not stored by INSERT with IF NOT EXISTS

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6069:

Labels: LWT  (was: )

> Sets not stored by INSERT with IF NOT EXISTS
> 
>
> Key: CASSANDRA-6069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6069
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eric Evans
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.2
>
> Attachments: 6069.txt
>
>
> An {{INSERT}} of a {{set}} column type is not stored when using {{IF NOT 
> EXISTS}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-2686) Distributed per row locks

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-2686:

Labels: LWT api-addition features  (was: api-addition features)

> Distributed per row locks
> -
>
> Key: CASSANDRA-2686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2686
> Project: Cassandra
>  Issue Type: Wish
> Environment: any
>Reporter: Luís Ferreira
>Priority: Major
>  Labels: LWT, api-addition, features
>
> Instead of using a centralized locking strategy like cages with zookeeper, I 
> would like to have it in a decentralized way. Even if it carries some 
> limitations. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6839) Support non equal conditions (for LWT)

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6839:

Labels: LWT  (was: )

> Support non equal conditions (for LWT)
> --
>
> Key: CASSANDRA-6839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6839
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Tyler Hobbs
>Priority: Minor
>  Labels: LWT
> Fix For: 2.1.1
>
> Attachments: 6839-2.1.txt, 6839-v2.txt, 6839-v3.txt, 6839.txt
>
>
> We currently only support equal conditions in conditional updates, but it 
> would be relatively trivial to support non-equal ones as well. At the very 
> least we should support '>', '>=', '<' and '<=', though it would probably 
> also make sense to add a non-equal relation too ('!=').



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6870) Transform operation

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6870:

Labels: LWT  (was: )

> Transform operation
> ---
>
> Key: CASSANDRA-6870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6870
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
>  Labels: LWT
>
> Compare and swap uses paxos to only update a value only if some criteria is 
> met. If I understand correctly we should be able to use this feature to 
> provide a wider variety of server side operations. 
> For example inside a paxos transaction performing a slice and then using a 
> function to manipulate the slice. You could accomplish features like append 
> and increment this way without user needing to know the current value.
> I took a stab at doing this. I **think** I did it correctly. Comments welcome.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7053) USING TIMESTAMP for batches does not work

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7053:

Labels: LWT cqlsh  (was: cqlsh)

> USING TIMESTAMP for batches does not work
> -
>
> Key: CASSANDRA-7053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7053
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Supencheck
>Assignee: Mikhail Stepura
>Priority: Major
>  Labels: LWT, cqlsh
> Fix For: 2.0.8
>
> Attachments: cassandra-2.0-7053.patch
>
>
> When using the "USING TIMESTAMP " syntax for a batch statement, 
> the supplied timestamp is ignored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7056) Add RAMP transactions

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7056:

Labels: LWT  (was: )

> Add RAMP transactions
> -
>
> Key: CASSANDRA-7056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7056
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Tupshin Harper
>Priority: Minor
>  Labels: LWT
> Fix For: 4.x
>
>
> We should take a look at 
> [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/]
>  transactions, and figure out if they can be used to provide more efficient 
> LWT (or LWT-like) operations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5925) Race condition in update lightweight transaction

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5925:

Labels: LWT  (was: )

> Race condition in update lightweight transaction
> 
>
> Key: CASSANDRA-5925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5925
> Project: Cassandra
>  Issue Type: Bug
> Environment: 3 node Cassandra 2.0.0-rc2 cluster. Java driver 1.0.2.
>Reporter: Phil Persad
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.0
>
> Attachments: 5925.txt, TokenConsumptionTest.java
>
>
> I'm building some tests for a Cassandra PoC.  One scenario I need to test is 
> consumption of 1 time tokens.  These tokens must be consumed exactly once.  
> The cluster involved is a 3 node cluster.  All queries are run with 
> ConsistencyLevel.QUORUM. I'm using the following queries:
> CREATE KEYSPACE IF NOT EXISTS test WITH replication = { 'class' : 
> 'SimpleStrategy', 'replication_factor' : 3 };
> CREATE TABLE IF NOT EXISTS tkns (tkn blob, consumed boolean, PRIMARY KEY 
> (tkn));
> INSERT INTO tkns (tkn, consumed) VALUES (?,FALSE) USING TTL 30;
> UPDATE tkns USING TTL 1 SET consumed = TRUE WHERE tkn = ? IF consumed = FALSE;
> I use the '[applied]' column in the result set of the update statement to 
> determine whether the token has been successfully consumed or if the token is 
> being replayed.
> My test involves concurrently executing many sets of 1 insert and 2 update 
> statements (using Session#execute on BoundStatemnts) then checking to make 
> sure that only one of the updates was applied.
> When I run this test with relatively few iterations (~100) my results are  
> what I expect (exactly 1 update succeeds).  At ~1000 iterations, I start 
> seeing both updates reporting success in 1-2% of cases.  While my test is 
> running, I see corresponding error entries in the Cassandra log:
> ERROR 15:34:53,583 Exception in thread Thread[MutationStage:522,5,main]
> java.lang.NullPointerException
> ERROR 15:34:53,584 Exception in thread Thread[MutationStage:474,5,main]
> java.lang.NullPointerException
> ERROR 15:34:53,584 Exception in thread Thread[MutationStage:536,5,main]
> java.lang.NullPointerException
> ERROR 15:34:53,729 Exception in thread Thread[MutationStage:480,5,main]
> java.lang.NullPointerException
> ERROR 15:34:53,729 Exception in thread Thread[MutationStage:534,5,main]
> java.lang.NullPointerException
> Thanks.
> Update:
> I'm not sure what's going on with the logging the the dev release.  I grabbed 
> the rc2 source and built that.  The resultant log is a bit more informative:
> ERROR 11:53:38,967 Exception in thread Thread[MutationStage:114,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.serializers.UUIDSerializer.deserialize(UUIDSerializer.java:32)
>   at 
> org.apache.cassandra.serializers.UUIDSerializer.deserialize(UUIDSerializer.java:26)
>   at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:142)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getUUID(UntypedResultSet.java:131)
>   at 
> org.apache.cassandra.db.SystemKeyspace.loadPaxosState(SystemKeyspace.java:785)
>   at 
> org.apache.cassandra.service.paxos.PaxosState.commit(PaxosState.java:118)
>   at 
> org.apache.cassandra.service.paxos.CommitVerbHandler.doVerb(CommitVerbHandler.java:34)
>   at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
>   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)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6270:

Labels: LWT  (was: )

> SERIAL consistency in errors to v1 protocol driver
> --
>
> Key: CASSANDRA-6270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6270
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.0
>Reporter: Theo Hultberg
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.3
>
> Attachments: 6270.txt
>
>
> I'm the author of the Ruby driver for CQL, and I got a bug report about 
> strange errors when running on C* 2.0 and using lightweight transaction 
> queries. The bug report can be found here: 
> https://github.com/iconara/cql-rb/issues/53
> The client sent {{UPDATE table SET val = 42 WHERE row_id = 5 IF val = 41}} 
> and when C* couldn't fulfill SERIAL consistency it sent an error back saying 
> "Operation timed out - received only -1 responses".
> So far so good, but it also set the {{consistency}} field in the error 
> response to 8, corresponding to {{SERIAL}} in v2 of the binary protocol, even 
> if the communication with the client was over v1 of the protocol. Since my 
> driver doesn't yet support v2 it doesn't think that 8 is a valid consistency, 
> and fails to parse the frame.
> Is this the intended behaviour of C*, or an oversight in how that error is 
> formulated? I could easily add {{SERIAL}} and accept it even if the 
> communication is over v1 of the protocol, but the bigger issue is how C* 
> handles drivers that do not speak the latest version of the protocol. People 
> should be able to use a driver that worked correctly with C* X with C* X+1, 
> right?
> Do drivers have to be accepting in what they receive from C* because they 
> might get consistencies, data types, etc. that are from future versions of 
> the protocol, or does C* guarantee that frames will conform to the protocol 
> that the driver says it understands?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5985) Paxos replay of in progress update is incorrect

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5985:

Labels: LWT  (was: )

> Paxos replay of in progress update is incorrect
> ---
>
> Key: CASSANDRA-5985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5985
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.1
>
>
> When we replay {{inProgress}}, we need to refresh it with the newly prepared 
> ballot, or it will be (correctly) rejected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-9200) Sequences

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9200:

Labels: LWT  (was: )

> Sequences
> -
>
> Key: CASSANDRA-9200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9200
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jonathan Ellis
>Priority: Major
>  Labels: LWT
>
> UUIDs are usually the right choice for surrogate keys, but sometimes 
> application constraints dictate an increasing numeric value.
> We could do this by using LWT to reserve "blocks" of the sequence for each 
> member of the cluster, which would eliminate paxos contention at the cost of 
> not being strictly increasing.
> PostgreSQL syntax: 
> http://www.postgresql.org/docs/9.4/static/sql-createsequence.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7942) Allow LWT batch to modify multiple partitions.

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7942:

Labels: LWT  (was: )

> Allow LWT batch to modify multiple partitions.
> --
>
> Key: CASSANDRA-7942
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7942
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Matt Stump
>Priority: Major
>  Labels: LWT
> Attachments: 2.0-7942.txt, trunk-7942.txt
>
>
> Summary: 
> Allow LWT batch to modify multiple partitions as long as all conditions use 
> the same partition.
> Example usage:
> Create user if not exists, and also populate inverted indexes for the user 
> entity. Batch conditions would continue to be limited to a single partition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-12060:
-
Labels: LWT  (was: )

> Establish consistent distinction between non-existing partition and NULL 
> value for LWTs on static columns
> -
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
>  Labels: LWT
> Fix For: 3.0.10, 3.10
>
>
> When executing following CQL commands: 
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int, 
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied] | s2
> ---+--
>  False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> {{2.x}} would although return same result if executed on a partition that 
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same 
> behaviour with non-static column LWTs. The most recent change was 
> [CASSANDRA-10532], which enabled LWT operations on static columns with 
> partition keys only. -Another possible relation is [CASSANDRA-9842], which 
> removed distinction between {{null}} column and non-existing row.- (striked 
> through since same happens on pre-[CASSANDRA-9842] code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-11991:
-
Labels: LWT  (was: )

> On clock skew, paxos may "corrupt" the node clock
> -
>
> Key: CASSANDRA-11991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11991
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.1.15, 2.2.7, 3.0.8, 3.8
>
>
> W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node 
> can "corrupt" other node clocks through Paxos. That wasn't intended and we 
> should fix that. I'll attach a patch later.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13509) Change system.paxos default compaction strategy to TWCS

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13509:
-
Labels: LWT  (was: )

> Change system.paxos default compaction strategy to TWCS
> ---
>
> Key: CASSANDRA-13509
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13509
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: LWT
> Fix For: 4.0, 4.x
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7176) error in cassandra log file under stress

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7176:

Labels: LWT  (was: )

> error in cassandra log file under stress
> 
>
> Key: CASSANDRA-7176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7176
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mohica Jasha
>Priority: Major
>  Labels: LWT
>
> We are using C* 2.0.5 with DC1:3, DC2:3 and datastax java-driver 2.0.1 in our 
> app-server.
> When we put our app-server under heavy stress testing. We got a 
> {{com.datastax.driver.core.exceptions.ReadTimeoutException}} from java-driver 
> and in the C* log file we got the following:
> {noformat}
> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794 
> QueryMessage.java (line 131) Unexpected error during query
> java.lang.UnsupportedOperationException: Invalid consistency level: 
> LOCAL_SERIAL
> at 
> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
> at 
> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
> at 
> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
> at 
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at 
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at 
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at 
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
> at 
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
> 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:744)
> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794 
> ErrorMessage.java (line 222) Unexpected exception during request
> java.lang.UnsupportedOperationException: Invalid consistency level: 
> LOCAL_SERIAL
> at 
> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
> at 
> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
> at 
> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
> at 
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at 
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at 
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at 
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
> at 
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
> 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:744)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: 

[jira] [Updated] (CASSANDRA-7044) LWT with SERIAL consistency gives misleading message on WriteTimeout

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7044:

Labels: LWT  (was: )

> LWT with SERIAL consistency gives misleading message on WriteTimeout
> 
>
> Key: CASSANDRA-7044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7044
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Adam Hattrell
>Priority: Major
>  Labels: LWT
>
> I have a user using LWT with SERIAL consistency.  We see the following stack 
> trace:
> {code:none}
> ERROR [Native-Transport-Requests:61112] 2014-04-16 10:39:05,437 
> ErrorMessage.java (line 222) Unexpected exception during request
> java.lang.UnsupportedOperationException: Invalid consistency level: SERIAL
> at 
> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
> at 
> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:361)
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:220)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:452)
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:407)
> at 
> org.apache.cassandra.cql3.QueryProcessor.executeWithHooks(QueryProcessor.java:201)
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:358)
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:131)
> at 
> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
> at 
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at 
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at 
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at 
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
> at 
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
> 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:744)
> {code}
> It looks as though when the paxos round timesout we call blockFor() which 
> currently doesn't support SERIAL.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-10532) Allow LWT operation on static column with only partition keys

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-10532:
-
Labels: LWT  (was: )

> Allow LWT operation on static column with only partition keys
> -
>
> Key: CASSANDRA-10532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10532
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: C* 2.2.0
>Reporter: DOAN DuyHai
>Assignee: Carl Yeksigian
>Priority: Major
>  Labels: LWT
> Fix For: 2.1.15, 2.2.7, 3.0.8, 3.8
>
>
> Schema
> {code:sql}
> CREATE TABLE IF NOT EXISTS achilles_embedded.entity_with_static_column(
> id bigint,
> uuid uuid,
> static_col text static,
> value text,
> PRIMARY KEY(id, uuid));
> {code}
> When trying to prepare the following query
> {code:sql}
> DELETE static_col FROM achilles_embedded.entity_with_static_column WHERE 
> id=:id_Eq IF static_col=:static_col;
> {code}
> I got the error *DELETE statements must restrict all PRIMARY KEY columns with 
> equality relations in order to use IF conditions, but column 'uuid' is not 
> restricted*
> Since the mutation only impacts the static column and the CAS check is on the 
> static column, it makes sense to provide only partition key



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7032) Improve vnode allocation

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7032:

Labels: LWT performance vnodes  (was: performance vnodes)

> Improve vnode allocation
> 
>
> Key: CASSANDRA-7032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7032
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Assignee: Branimir Lambov
>Priority: Major
>  Labels: LWT, performance, vnodes
> Fix For: 3.0 alpha 1
>
> Attachments: TestVNodeAllocation.java, TestVNodeAllocation.java, 
> TestVNodeAllocation.java, TestVNodeAllocation.java, TestVNodeAllocation.java, 
> TestVNodeAllocation.java
>
>
> It's been known for a little while that random vnode allocation causes 
> hotspots of ownership. It should be possible to improve dramatically on this 
> with deterministic allocation. I have quickly thrown together a simple greedy 
> algorithm that allocates vnodes efficiently, and will repair hotspots in a 
> randomly allocated cluster gradually as more nodes are added, and also 
> ensures that token ranges are fairly evenly spread between nodes (somewhat 
> tunably so). The allocation still permits slight discrepancies in ownership, 
> but it is bound by the inverse of the size of the cluster (as opposed to 
> random allocation, which strangely gets worse as the cluster size increases). 
> I'm sure there is a decent dynamic programming solution to this that would be 
> even better.
> If on joining the ring a new node were to CAS a shared table where a 
> canonical allocation of token ranges lives after running this (or a similar) 
> algorithm, we could then get guaranteed bounds on the ownership distribution 
> in a cluster. This will also help for CASSANDRA-6696.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-9649) Paxos ballot in StorageProxy could clash

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9649:

Labels: LWT  (was: )

> Paxos ballot in StorageProxy could clash
> 
>
> Key: CASSANDRA-9649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9649
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Stefania
>Assignee: Stefania
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.17, 2.1.8, 2.2.0 rc2
>
>
> This code in {{StorageProxy.beginAndRepairPaxos()}} takes a timestamp in 
> microseconds but divides it by 1000 before adding one. So if the summary is 
> null, ballotMillis would be the same for up to 1000 possible state timestamp 
> values:
> {code}
> long currentTime = (state.getTimestamp() / 1000) + 1;
> long ballotMillis = summary == null
>  ? currentTime
>  : Math.max(currentTime, 1 +
> UUIDGen.unixTimestamp(summary.mostRecentInProgressCommit.ballot));
> UUID ballot = UUIDGen.getTimeUUID(ballotMillis);
> {code}
> {{state.getTimestamp()}} returns the time in micro seconds and it ensures to 
> add one microsecond to any previously used timestamp if the client sends the 
> same or an older timestamp. 
> Initially I used this code in {{ModificationStatement.casInternal()}}, 
> introduced by CASSANDRA-9160 to support cas unit tests, but occasionally 
> these tests were failing. It was only when I ensured uniqueness of the ballot 
> that the tests started to pass reliably.
> I wonder if we could ever have the same issue in StorageProxy?
> cc [~jbellis] and [~slebresne] for CASSANDRA-7801



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-10887:
-
Labels: LWT  (was: )

> Pending range calculator gives wrong pending ranges for moves
> -
>
> Key: CASSANDRA-10887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10887
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Richard Low
>Assignee: sankalp kohli
>Priority: Critical
>  Labels: LWT
> Fix For: 2.1.13, 2.2.5, 3.0.3, 3.3
>
> Attachments: CASSANDRA-10887.diff, CASSANDRA_10887_2.2.diff, 
> CASSANDRA_10887_3.0.diff, CASSANDRA_10887_v2.diff, CASSANDRA_10887_v3.diff
>
>
> My understanding is the PendingRangeCalculator is meant to calculate who 
> should receive extra writes during range movements. However, it adds the 
> wrong ranges for moves. An extreme example of this can be seen in the 
> following reproduction. Create a 5 node cluster (I did this on 2.0.16 and 
> 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and 
> immediately kill -9 it. Now you see a node as down and moving in the ring. 
> Try a quorum write for a partition that is stored on that node - it will fail 
> with a timeout. Further, all CAS reads or writes fail immediately with 
> unavailable exception because they attempt to include the moving node twice. 
> This is likely to be the cause of CASSANDRA-10423.
> In my example I had this ring:
> 127.0.0.1  rack1   Up Normal  170.97 KB   20.00%  
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  124.06 KB   20.00%  
> -5534023222112865485
> 127.0.0.3  rack1   Down   Moving  108.7 KB40.00%  
> 1844674407370955160
> 127.0.0.4  rack1   Up Normal  142.58 KB   0.00%   
> 1844674407370955161
> 127.0.0.5  rack1   Up Normal  118.64 KB   20.00%  
> 5534023222112865484
> Node 3 was moving to -1844674407370955160. I added logging to print the 
> pending and natural endpoints. For ranges owned by node 3, node 3 appeared in 
> pending and natural endpoints. The blockFor is increased to 3 so we’re 
> effectively doing CL.ALL operations. This manifests as write timeouts and CAS 
> unavailables when the node is down.
> The correct pending range for this scenario is node 1 is gaining the range 
> (-1844674407370955160, 1844674407370955160). So node 1 should be added as a 
> destination for writes and CAS for this range, not node 3.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13793) Regression in 3.0, breaking the fix from CASSANDRA-6069

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13793:
-
Labels: LWT  (was: )

> Regression in 3.0, breaking the fix from CASSANDRA-6069
> ---
>
> Key: CASSANDRA-13793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13793
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 3.0.x, 3.11.x
>
>
> The goal of the fix of CASSANDRA-6069 was to make sure that collection 
> tombstones in an update in CAS were using {{t-1}} because at least in 
> {{INSERT}} collection tombstones are used to delete data prior to the update 
> but shouldn't delete the newly inserted data itself. Because in 2.x the 
> collection tombstones are normal range tombstones and thus part of the 
> {{DeletionInfo}}, we went with the easy solution of using {{t-1}} for all of 
> {{DeletionInfo}}.
> When moving that code to 3.0, this was migrated too literally however and 
> only the {{DeletionInfo}} got the {{t -1}}. But in 3.0, range tombstones are 
> not part of {{DeletionInfo}} anymore, and so this is broken.
> Thanks to [~aweisberg] for noticing this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7804) Confusing error message when condition is set on primary key column

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7804:

Labels: LWT  (was: )

> Confusing error message when condition is set on primary key column
> ---
>
> Key: CASSANDRA-7804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7804
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Minor
>  Labels: LWT
> Fix For: 2.1.1
>
> Attachments: 7804-2.1.txt
>
>
> If you set a CAS condition on a primary key column, you'll get an error 
> that's somewhat confusing:
> {noformat}
> cqlsh:ks1> CREATE TABLE mytable (a int PRIMARY KEY, b int);
> cqlsh:ks1> UPDATE mytable SET b = 0 WHERE a = 0 IF a = 0;
> code=2200 [Invalid query] message="PRIMARY KEY part a found in SET part"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7155) Followup to 6914: null handling, duplicate column in resultSet and cleanup

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7155:

Labels: LWT  (was: )

> Followup to 6914: null handling, duplicate column in resultSet and cleanup
> --
>
> Key: CASSANDRA-7155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7155
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.8
>
>
> The patch for CASSANDRA-6914 left a few stuffs not properly handled:
> # A condition like {{IF m['foo'] = null}} is not handled and throw a NPE.
> # It's using ByteBuffer.equals() to compare 2 collection values which is 
> generally incorrect (the actual comparator should be used).
> # If 2 conditions on 2 elements of the same collection were provided and the 
> CAS failed, then the collection was duplicated in the resultSet.
> # The ColumnCondition.WithVariables was generally a bit inefficient/ugly: it 
> can lead to bind multiple times the same terms which is unnecessary. It's 
> cleaner to directly create a condition with bound values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8446) Lost writes when using lightweight transactions

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-8446:

Labels: LWT  (was: )

> Lost writes when using lightweight transactions
> ---
>
> Key: CASSANDRA-8446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8446
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Cassandra 2.1.2 on Java(TM) SE Runtime Environment 
> (build 1.7.0_65-b17)
>Reporter: Jochen Zeischka
>Priority: Major
>  Labels: LWT
> Fix For: 2.1.5
>
>
> 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
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6836) WriteTimeoutException always reports that the serial CL is "SERIAL"

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6836:

Labels: LWT lhf  (was: lhf)

> WriteTimeoutException always reports that the serial CL is "SERIAL"
> ---
>
> Key: CASSANDRA-6836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6836
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Nicolas Favre-Felix
>Assignee: Irfan Nagoo
>Priority: Minor
>  Labels: LWT, lhf
> Attachments: trunk-6836.txt
>
>
> In StorageProxy.proposePaxos, the WriteTimeoutException is thrown with 
> information about the consistency level. This CL is hardcoded to 
> ConsistencyLevel.SERIAL, which might be wrong when LOCAL_SERIAL is used:
> {code}
> if (timeoutIfPartial && !callback.isFullyRefused())
> throw new WriteTimeoutException(WriteType.CAS, 
> ConsistencyLevel.SERIAL, callback.getAcceptCount(), requiredParticipants);
> {code}
> Suggested fix: pass consistencyForPaxos as a parameter to proposePaxos().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7538) Truncate of a CF should also delete Paxos CF

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7538:

Labels: LWT  (was: )

> Truncate of a CF should also delete Paxos CF
> 
>
> Key: CASSANDRA-7538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7538
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: sankalp kohli
>Assignee: Sam Tunnicliffe
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.12, 2.1.3
>
> Attachments: 7538.txt
>
>
> We don't delete data from Paxos CF during truncate. This will cause data to 
> come back in the next CAS round for incomplete commits. 
> Also I am not sure whether we already do this but should we also not truncate 
> hints for that CF. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-12694:
-
Labels: LWT  (was: )

> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
>Priority: Major
>  Labels: LWT
> Fix For: 3.0.11, 3.10
>
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [main/:na]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13109) Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13109:
-
Labels: LWT  (was: )

> Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0
> ---
>
> Key: CASSANDRA-13109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13109
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Klock
>Assignee: Samuel Klock
>Priority: Major
>  Labels: LWT
> Fix For: 3.0.11, 3.11.0
>
> Attachments: 13109-3.0.txt
>
>
> We've observed this upgrading from 2.1.15 to 3.0.8 and from 2.1.16 to 3.0.10: 
> some lightweight transactions executed on upgraded nodes fail with a read 
> failure.  The following conditions seem relevant to this occurring:
> * The transaction must be conditioned on the current value of at least one 
> column, e.g., {{IF NOT EXISTS}} transactions don't seem to be affected.
> * There should be a collection column (in our case, a map) defined on the 
> table on which the transaction is executed.
> * The transaction should be executed before sstables on the node are 
> upgraded.  The failure does not occur after the sstables have been upgraded 
> (whether via {{nodetool upgradesstables}} or effectively via compaction).
> * Upgraded nodes seem to be able to participate in lightweight transactions 
> as long as they're not the coordinator.
> * The values in the row being manipulated by the transaction must have been 
> consistently manipulated by lightweight transactions (perhaps the existence 
> of Paxos state for the partition is somehow relevant?).
> * In 3.0.10, it _seems_ to be necessary to have the partition split across 
> multiple legacy sstables.  This was not necessary to reproduce the bug in 
> 3.0.8 or .9.
> For applications affected by this bug, a possible workaround is to prevent 
> nodes being upgraded from coordinating requests until sstables have been 
> upgraded.
> We're able to reproduce this when upgrading from 2.1.16 to 3.0.10 with the 
> following steps on a single-node cluster using a mostly pristine 
> {{cassandra.yaml}} from the source distribution.
> # Start Cassandra-2.1.16 on the node.
> # Create a table with a collection column and insert some data into it.
> {code:sql}
> CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE test.test (key TEXT PRIMARY KEY, cas_target TEXT, 
> some_collection MAP);
> INSERT INTO test.test (key, cas_target, some_collection) VALUES ('key', 
> 'value', {}) IF NOT EXISTS;
> {code}
> # Flush the row to an sstable: {{nodetool flush}}.
> # Update the row:
> {code:sql}
> UPDATE test.test SET cas_target = 'newvalue', some_collection = {} WHERE key 
> = 'key' IF cas_target = 'value';
> {code}
> # Drain the node: {{nodetool drain}}
> # Stop the node, upgrade to 3.0.10, and start the node.
> # Attempt to update the row again:
> {code:sql}
> UPDATE test.test SET cas_target = 'lastvalue' WHERE key = 'key' IF cas_target 
> = 'newvalue';
> {code}
> Using {{cqlsh}}, if the error is reproduced, the following output will be 
> returned:
> {code:sql}
> $ ./cqlsh <<< "UPDATE test.test SET cas_target = 'newvalue', some_collection 
> = {} WHERE key = 'key' IF cas_target = 'value';"
> (start: 2016-12-22 10:14:27 EST)
> :2:ReadFailure: Error from server: code=1300 [Replica(s) failed to 
> execute read] message="Operation failed - received 0 responses and 1 
> failures" info={'failures': 1, 'received_responses': 0, 'required_responses': 
> 1, 'consistency': 'QUORUM'}
> {code}
> and the following stack trace will be present in the system log:
> {noformat}
> WARN  15:14:28 Uncaught exception on thread 
> Thread[SharedPool-Worker-10,10,main]: {}
> java.lang.RuntimeException: java.lang.NullPointerException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2476)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_101]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[main/:na]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.lang.NullPointerException: null
>   at 
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:617)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:569)
>  

[jira] [Updated] (CASSANDRA-9966) Option to apply statements within a batch sequentially

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9966:

Labels: LWT  (was: )

> Option to apply statements within a batch sequentially
> --
>
> Key: CASSANDRA-9966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Sam Overton
>Priority: Major
>  Labels: LWT
> Fix For: 4.x
>
>
> It is possible to batch CAS statements such that their outcome is different 
> to the outcome were they executed sequentially outside of a batch.
> eg.
> a | b | c
> a | 1 | 1
> BEGIN BATCH
> UPDATE foo SET b=2 WHERE a='a' iF c=1
> UPDATE foo SET c=2 WHERE a='a' IF b=1
> APPLY BATCH
> results in 
> a | b | c
> a | 2 | 2
> If these statements were not batched, the outcome would be 
> UPDATE foo SET b=2 WHERE a='a' iF c=1
> a | b | c
> a | 2 | 1
> UPDATE foo SET c=2 WHERE a='a' IF b=1
> applied=false (pre-condition b=1 not met)
> Cassandra already checks for incompatible preconditions within a batch (eg 
> one statement with IF c=1 and another statement with IF c=2). It should also 
> check for mutations to columns in one statement that affect the 
> pre-conditions of another statement, or it should evaluate the statement 
> pre-conditions sequentially after applying the mutations of the previous 
> statement to an in-memory model of the partition.
> For backwards compatibility this would have to be a new "strict" batch mode, 
> eg.
> BEGIN STRICT BATCH



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-10423) Paxos/LWT failures when moving node

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-10423:
-
Labels: LWT  (was: )

> Paxos/LWT failures when moving node
> ---
>
> Key: CASSANDRA-10423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10423
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra version: 2.0.14
> Java-driver version: 2.0.11
>Reporter: Roger Schildmeijer
>Priority: Major
>  Labels: LWT
>
> While moving a node (nodetool move ) we noticed that lwt started 
> failing for some (~50%) requests. The java-driver (version 2.0.11) returned 
> com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout 
> during write query at consistency SERIAL (7 replica were required but only 0 
> acknowledged the write). The cluster was not under heavy load.
> I noticed that the failed lwt requests all took just above 1s. That 
> information and the WriteTimeoutException could indicate that this happens:
> https://github.com/apache/cassandra/blob/cassandra-2.0.14/src/java/org/apache/cassandra/service/StorageProxy.java#L268
> I can't explain why though. Why would there be more cas contention just 
> because a node is moving?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8051) Add SERIAL and LOCAL_SERIAL consistency levels to cqlsh

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-8051:

Labels: LWT cqlsh  (was: cqlsh)

> Add SERIAL and LOCAL_SERIAL consistency levels to cqlsh
> ---
>
> Key: CASSANDRA-8051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8051
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Nicolas Favre-Felix
>Assignee: Carl Yeksigian
>Priority: Minor
>  Labels: LWT, cqlsh
> Fix For: 2.0.15, 2.1.6
>
> Attachments: 8051-2.0.txt, 8051-2.1-v2.txt, 8051-2.1-v3.txt, 
> 8051-2.1.txt, log-statements-2.0.txt, log-statements-2.1.txt, 
> python-driver-fix.txt
>
>
> cqlsh does not support setting the serial consistency level. The default 
> CL.SERIAL does not let users safely execute LWT alongside an app that runs at 
> LOCAL_SERIAL, and can prevent any LWT from running when a DC is down (e.g. 
> with 2 DCs, RF=3 in each.)
> Implementing this well is a bit tricky. A user setting the serial CL will 
> probably not want all of their statements to have a serial CL attached, but 
> only the conditional updates. At the same time it would be useful to support 
> serial reads. "WITH CONSISTENCY LEVEL" used to provide this flexibility.
> I believe that it is currently impossible to run a SELECT at SERIAL or 
> LOCAL_SERIAL; the only workaround seems to be to run a conditional update 
> with a predicate that always resolves to False, and to rely on the CAS 
> response to read the data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6584) LOCAL_SERIAL doesn't work from Thrift

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6584:

Labels: LWT easyfix  (was: easyfix)

> LOCAL_SERIAL doesn't work from Thrift
> -
>
> Key: CASSANDRA-6584
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6584
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Nicolas Favre-Felix
>Assignee: Brandon Williams
>Priority: Major
>  Labels: LWT, easyfix
> Fix For: 2.0.5
>
> Attachments: 6584.txt
>
>
> Calling "cas" from Thrift with CL.LOCAL_SERIAL fails with an AssertionError 
> since ThriftConversion.fromThrift has no "case" statement for LOCAL_SERIAL.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-14281) Improve LatencyMetrics performance by reducing write path processing

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-14281:
-
Labels: LWT perfomance  (was: perfomance)

> Improve LatencyMetrics performance by reducing write path processing
> 
>
> Key: CASSANDRA-14281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14281
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Michael Burman
>Assignee: Michael Burman
>Priority: Major
>  Labels: LWT, perfomance
> Fix For: 4.0
>
> Attachments: bench.png, bench2.png, benchmark.html, benchmark2.png
>
>
> Currently for each write/read/rangequery/CAS touching the CFS we write a 
> latency metric which takes a lot of processing time (up to 66% of the total 
> processing time if the update was empty). 
> The way latencies are recorded is to use both a dropwizard "Timer" as well as 
> "Counter". Latter is used for totalLatency and the previous is decaying 
> metric for rates and certain percentile metrics. We then replicate all of 
> these CFS writes to the KeyspaceMetrics and globalWriteLatencies. 
> Instead of doing this on the write phase we should merge the metrics when 
> they're read. This is much less common occurrence and thus we save a lot of 
> CPU time in total. This also speeds up the write path.
> Currently, the DecayingEstimatedHistogramReservoir acquires a lock for each 
> update operation, which causes a contention if there are more than one thread 
> updating the histogram. This impacts scalability when using larger machines. 
> We should make it lock-free as much as possible and also avoid a single 
> CAS-update from blocking all the concurrent threads from making an update.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7344) Read at SERIAL can lead to unnecessary contention

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7344:

Labels: LWT  (was: )

> Read at SERIAL can lead to unnecessary contention 
> --
>
> Key: CASSANDRA-7344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7344
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
>
> If two clients are doing a read at serial on the same row, it does a full 
> prepare step to figure out whether there is any updates or cas in flight or 
> uncompleted. 
> This can cause contention between then leading to waste of time in retrying. 
> One of the request will not get a promise and will need to sleep. 
> Instead they can check whether there is anything to finish and if not 
> continue. 
> If there is something to be done, then they can do the full prepare. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13508) Make system.paxos table compaction strategy configurable

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13508:
-
Labels: LWT core paxos  (was: core paxos)

> Make system.paxos table compaction strategy configurable
> 
>
> Key: CASSANDRA-13508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13508
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Major
>  Labels: LWT, core, paxos
> Fix For: 4.0, 4.x
>
> Attachments: test11.png, test2.png
>
>
> The default compaction strategy for {{system.paxos}} table is LCS for 
> performance reason: CASSANDRA-7753. But for CAS heavily used cluster, the 
> system is busy with {{system.paxos}} compaction.
> As the data in {{paxos}} table are TTL'ed, TWCS might be a better fit. In our 
> test, it significantly reduced the number of compaction without impacting the 
> latency too much:
> !test11.png!
> The time window for TWCS is set to 2 minutes for the test.
> Here is the p99 latency impact:
> !test2.png!
> the yellow one is LCS, the purple one is TWCS. Average p99 has about 10% 
> increase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-48) test-and-set

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-48:
--
Labels: LWT  (was: )

> test-and-set
> 
>
> Key: CASSANDRA-48
> URL: https://issues.apache.org/jira/browse/CASSANDRA-48
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Priority: Major
>  Labels: LWT
>
> Atomic test-and-set insert operation would be nice: "set value to X but only 
> if the current value is still Y."  This allows a sort of optimistic 
> consistency: perform a GET, then perform test-and-set with the value of that 
> GET as Y.
> I do not think that this requires strong consistency to be useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-1984) Implement "check and set"

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-1984:

Labels: LWT  (was: )

> Implement "check and set"
> -
>
> Key: CASSANDRA-1984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1984
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Max Sanders
>Priority: Major
>  Labels: LWT
> Fix For: 0.7.1
>
>
> When fetching data from cassandra you should ask for a hash value for the 
> stored value. Then when updating a value it should be possible to submit this 
> hash value and only update the data when the hash key is still the same.
> This way you can be sure that the data was not changed on this node.
> It is the same as the memcached CAS Feature.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6495) LOCAL_SERIAL use QUORAM consistency level to validate expected columns

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6495:

Labels: LWT  (was: )

> LOCAL_SERIAL  use QUORAM consistency level to validate expected columns
> ---
>
> Key: CASSANDRA-6495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6495
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.5
>
> Attachments: trunk_6495.diff
>
>
> If CAS is done at LOCAL_SERIAL consistency level, only the nodes from the 
> local data center should be involved. 
> Here we are using QUORAM to validate the expected columns. This will require 
> nodes from more than one DC. 
> We should use LOCAL_QUORAM here when CAS is done at LOCAL_SERIAL. 
> Also if we have 2 DCs with DC1:3,DC2:3, a single DC down will cause CAS to 
> not work even for LOCAL_SERIAL. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6495) LOCAL_SERIAL use QUORUM consistency level to validate expected columns

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6495:

Summary: LOCAL_SERIAL  use QUORUM consistency level to validate expected 
columns  (was: LOCAL_SERIAL  use QUORAM consistency level to validate expected 
columns)

> LOCAL_SERIAL  use QUORUM consistency level to validate expected columns
> ---
>
> Key: CASSANDRA-6495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6495
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.5
>
> Attachments: trunk_6495.diff
>
>
> If CAS is done at LOCAL_SERIAL consistency level, only the nodes from the 
> local data center should be involved. 
> Here we are using QUORAM to validate the expected columns. This will require 
> nodes from more than one DC. 
> We should use LOCAL_QUORAM here when CAS is done at LOCAL_SERIAL. 
> Also if we have 2 DCs with DC1:3,DC2:3, a single DC down will cause CAS to 
> not work even for LOCAL_SERIAL. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7724) Native-Transport threads get stuck in StorageProxy.preparePaxos with no one making progress

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7724:

Labels: LWT  (was: )

> Native-Transport threads get stuck in StorageProxy.preparePaxos with no one 
> making progress
> ---
>
> Key: CASSANDRA-7724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7724
> Project: Cassandra
>  Issue Type: Bug
> Environment: Linux 3.13.11-4 #4 SMP PREEMPT x86_64 Intel(R) Core(TM) 
> i7 CPU 950 @ 3.07GHz GenuineIntel 
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> cassandra 2.0.9
>Reporter: Anton Lebedevich
>Priority: Major
>  Labels: LWT
> Attachments: aggregateddump.txt, cassandra.threads2
>
>
> We've got a lot of write timeouts (cas) when running 
> "INSERT INTO cas_demo(pri_id, sec_id, flag, something) VALUES(?, ?, ?, ?) IF 
> NOT EXISTS"
>  from 16 connections in parallel using the same pri_id and different sec_id.
> Doing the same from 4 connections in parallel works ok.
> All configuration values are at their default values.
> CREATE TABLE cas_demo (
>   pri_id varchar,
>   sec_id varchar,
>   flag boolean,
>   something set,
>   PRIMARY KEY (pri_id, sec_id)
> );
> CREATE INDEX cas_demo_flag ON cas_demo(flag);
> Full thread dump is attached. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-9330) CAS timeout errors should use a different exception than WriteTimeoutException as WTE can happen when nodes fail to respond.

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9330:

Labels: LWT  (was: )

> CAS timeout errors should use a different exception than 
> WriteTimeoutException as WTE can happen when nodes fail to respond.
> 
>
> Key: CASSANDRA-9330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9330
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Aaron Whiteside
>Priority: Major
>  Labels: LWT
>
> Perhaps a CASContentionTimeoutException?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6437) Datastax C# driver not able to execute CAS after upgrade 2.0.2 -> 2.0.3

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6437:

Labels: LWT  (was: )

> Datastax C# driver not able to execute CAS after upgrade 2.0.2 -> 2.0.3
> ---
>
> Key: CASSANDRA-6437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6437
> Project: Cassandra
>  Issue Type: Bug
> Environment: 4 node Centod 6.4 x64 casandra 2.0.3 (datastax community)
>Reporter: Michał Ziemski
>Priority: Major
>  Labels: LWT
>
> The following code:
>   var cl = 
> Cluster.Builder().WithConnectionString(ConfigurationManager.ConnectionStrings.["Cassandra"].ConnectionString).Build();
>   var  ses = cl.Connect();
>   ses.Execute("INSERT INTO appsrv(id) values ('abc') IF NOT EXISTS", 
> ConsistencyLevel.Quorum);
> Worked fine with cassandra 2.0.2
> After upgrading to 2.0.3 I get an error stating that conditional updates are 
> not supported by the protocol version and I should upgrade to v2.
> I'm not really sure if it's a problem with C* or the Datastax C# Driver.
> The error appeared afeter upgrading C* so I decided to post it here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6023) CAS should distinguish promised and accepted ballots

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6023:

Labels: LWT  (was: )

> CAS should distinguish promised and accepted ballots
> 
>
> Key: CASSANDRA-6023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6023
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.1
>
> Attachments: 
> 0001-Distinguish-between-promised-and-accepted-ballots.txt, 
> 0002-Populate-commitsByReplica-in-PrepareCallback.txt
>
>
> Currently, we only keep 1) the most recent promise we've made and 2) the last 
> update we've accepted. But we don't keep the ballot at which that last update 
> was accepted. And because a node always promise to newer ballot, this means 
> an already committed update can be replayed even after another update has 
> been committed. Re-committing a value is fine, but only as long as we've not 
> start a new round yet.
> Concretely, we can have the following case (with 3 nodes A, B and C) with the 
> current implementation:
> * A proposer P1 prepare and propose a value X at ballot t1. It is accepted by 
> all nodes.
> * A proposer P2 propose at t2 (wanting to commit a new value Y). If say A and 
> B receive the commit of P1 before the propose of P2 but C receives those in 
> the reverse order, we'll current have the following states:
> {noformat}
> A: in-progress = (t2, _), mrc = (t1, X)
> B: in-progress = (t2, _), mrc = (t1, X)
> C: in-progress = (t2, X), mrc = (t1, X)
> {noformat}
> Because C has received the t1 commit after promising t2, it won't have 
> removed X during t1 commit (but note that the problem is not during commit, 
> that example still stand if C never receive any commit message).
> * Now, based on the promise of A and B, P2 will propose Y at t2 (C don't see 
> this propose in particular, not before he promise on t3 below at least). A 
> and B accepts, P2 will send a commit for Y.
> * In the meantime a proposer P3 submit a prepare at t3 (for some other 
> irrelevant value) which reaches C before it receives P2 propose That 
> prepare reaches A and B too, but after the P2 commit. At that point the state 
> will be:
> {noformat}
> A: in-progress = (t3, _), mrc = (t2, Y)
> B: in-progress = (t3, _), mrc = (t2, Y)
> C: in-progress = (t3, X), mrc = (t2, Y)
> {noformat}
> In particular, C still has X as update because each time it got a commit, it 
> has promised to a more recent ballot and thus skipped the delete. The value 
> is still X because it has received the P2 propose after having promised t3 
> and has thus refused it.
> * P3 gets back the promise of say C and A. Both response has t3 as 
> in-progress ballot (and it is more recent than any mrc) but C comes with 
> value X. So P3 will replay X. Assuming no more contention this replay will 
> succeed and X will be committed at t3.
> At the end of that example, we've comitted X, Y and then X again, even though 
> only P1 has ever proposed X.
> I believe the correct fix is to keep the ballot of when an update is accepted 
> (instead of using the most recent promised ballot). That way, in the example 
> above, P3 would receive from C a promise on t3, but would know that X was 
> accepted at t1. And so P3 would be able to ignore X since the mrc of A will 
> tell him it's an obsolete value.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6914) Map element is not allowed in CAS condition with DELETE/UPDATE query

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6914:

Labels: LWT  (was: )

> Map element is not allowed in CAS condition with DELETE/UPDATE query
> 
>
> Key: CASSANDRA-6914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6914
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dmitriy Ukhlov
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.7
>
> Attachments: 6914.txt
>
>
> {code}
> CREATE TABLE test (id int, data map, PRIMARY KEY(id));
> INSERT INTO test (id, data) VALUES (1,{'a':'1'});
> DELETE FROM test WHERE id=1 IF data['a']=null;
> Bad Request: line 1:40 missing EOF at '='
> UPDATE test SET data['b']='2' WHERE id=1 IF data['a']='1';
> Bad Request: line 1:53 missing EOF at '='
> {code}
> These queries was successfuly executed with cassandra 2.0.5, but don't work 
> in 2.0.6 release



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6012) CAS does not always correctly replay inProgress rounds

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6012:

Labels: LWT  (was: )

> CAS does not always correctly replay inProgress rounds
> --
>
> Key: CASSANDRA-6012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6012
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.1
>
> Attachments: 
> 0001-Don-t-skip-paxos-old-round-replay-if-there-is-a-value-.txt
>
>
> Paxos says that on receiving the result of a prepare from a quorum of 
> acceptors, the proposer should propose the value of the higher-number 
> proposal accepted amongst the ones returned by the acceptors, and only 
> propose his own value if no acceptor has send us back a previously accepted 
> value.
> But in PrepareCallback we only keep the more recent inProgress commit 
> regardless of whether is has an update. Which means we could ignore a value 
> already accepted by some acceptors if any of the acceptor send us a more 
> recent ballot than the other acceptor but with no values. The net effect is 
> that we can mistakenly accept two different values for the same round.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6013:

Labels: LWT  (was: )

> CAS may return false but still commit the insert
> 
>
> Key: CASSANDRA-6013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6013
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Jonathan Ellis
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.1
>
> Attachments: 6013-v2.txt, 6013-v3.txt, 6013-v4.patch, 6013.txt
>
>
> If a Paxos proposer proposes some value/update and that propose fail, there 
> is no guarantee on whether this value will be accepted or not ultimately. 
> Paxos guarantees that we'll agree on "a" value (for a given round in our 
> case), but does not guarantee that the proposer of the agreed upon value will 
> know it.  In particular, if for a given proposal at least one accepter has 
> accepted it but not a quorum does, then that value might (but that's not 
> guaranteed either) be replayed (and committed) by another proposer.
> Currently, if a proposer A proposes some update U but it is rejected, A will 
> sleep a bit and retry U. But if U was accepted by at least one acceptor, some 
> other proposer B might replay U, succeed and commit it. If A does its retry 
> after that happens, he will prepare, check the condition, and probably find 
> that the conditions don't apply anymore since U has been committed already. 
> It will thus return false, even though U has been in fact committed.
> Unfortunately I'm not sure there is an easy way for a proposer whose propose 
> fails to know if the update will prevail or not eventually. Which mean the 
> only acceptable solution I can see would be to return to the user "I don't 
> know" (through some exception for instance). Which is annoying because having 
> a proposal rejected won't be an extremely rare occurrence, even with 
> relatively light contention, and returning "I don't know" often is a bit 
> unfriendly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8335) Support CAS with UPDATE...IF col=val OR NOT EXISTS

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-8335:

Labels: LWT cas cql  (was: cas cql)

> Support CAS with UPDATE...IF col=val OR NOT EXISTS
> --
>
> Key: CASSANDRA-8335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8335
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Robert Stupp
>Priority: Minor
>  Labels: LWT, cas, cql
>
> On the -dev mailing list the RFE to extend UPDATE LWT using something like
> {{UPDATE ... IF col=val ... OR NOT EXISTS}}
> RFE is to add the {{OR NOT EXISTS}} which means either the the {{IF}} 
> conditions are met *xor* the row does not exist.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7345) Unfinished or inflight CAS are always done at QUORUM

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7345:

Labels: LWT  (was: )

> Unfinished or inflight CAS are always done at QUORUM
> 
>
> Key: CASSANDRA-7345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7345
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.10, 2.1 rc3
>
> Attachments: trunk-7345.diff
>
>
> The problem here is that we don't know which consistency level was used to 
> perform the operation. 
> We might want to store this in paxos cf or use the consistency level of the 
> current call. 
> This is important because calls being done at LOCAL_SERIAL will become slow. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5945) CAS transactions permitting multiple updates

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5945:

Labels: LWT  (was: )

> CAS transactions permitting multiple updates
> 
>
> Key: CASSANDRA-5945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5945
> Project: Cassandra
>  Issue Type: Bug
> Environment: 3 node Cassandra 2.0.0-rc2 cluster
> Java driver 1.0.2
> Replication factor 3
> Quorum consistency
>Reporter: Phil Persad
>Priority: Major
>  Labels: LWT
> Attachments: TokenConsumptionTest.java
>
>
> This bug is spawned off CASSANDRA-5925 to track an underlying issue not 
> related to TTLs.  To reproduce:
> Step 1:
> CREATE TABLE IF NOT EXISTS tkns (tkn blob, consumed boolean, PRIMARY KEY 
> (tkn));
> Step 2:
> INSERT INTO tkns (tkn, consumed) VALUES (?,FALSE);
> Step 3:
> UPDATE tkns SET consumed = TRUE WHERE tkn = ? IF consumed = FALSE;
> Step 4:
> UPDATE tkns SET consumed = TRUE WHERE tkn = ? IF consumed = FALSE;
> Repeat steps 2-4 about 100,000 times.
> Expectation:
> For the '[applied]' column in the result sets for steps 3 and 4, exactly one 
> should be true and one should be false.
> Bug:
> In a small number of cases (varying from 0.002% to 1%) both updates will 
> report success.  See attached unit test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7341) Emit metrics related to CAS/Paxos

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7341:

Labels: LWT  (was: )

> Emit metrics related to CAS/Paxos
> -
>
> Key: CASSANDRA-7341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7341
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.11, 2.1.1
>
> Attachments: 7341_2.0.txt, CASClientRequestMetrics.java, 
> trunk-7341-v2.diff, trunk-7341.diff
>
>
> We can emit metrics based on Paxos. One of them is when there is contention. 
> I will add more metric in this JIRA if it is helpful. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7954) Skip paxos for CAS if RF=1

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7954:

Labels: LWT performance  (was: performance)

> Skip paxos for CAS if RF=1
> --
>
> Key: CASSANDRA-7954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7954
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Benedict
>Priority: Minor
>  Labels: LWT, performance
>
> If RF=1, there's no point doing a paxos round - we get just as much safety 
> and atomicity by simply conditionally applying the update locally



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8640) Paxos requires all nodes for CAS

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-8640:

Labels: LWT qa-resolved  (was: qa-resolved)

> Paxos requires all nodes for CAS
> 
>
> Key: CASSANDRA-8640
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
>Priority: Major
>  Labels: LWT, qa-resolved
> Fix For: 2.0.12, 2.1.3
>
> Attachments: 0001-Fix-parentheses-bug-in-Paxos.patch, 
> 0001-Fix-quorum-required-nodes-calculation-for-Paxos.patch
>
>
> In C* 2.1,
> {code}
> int requiredParticipants = participants + 1  / 2; // See CASSANDRA-833
> {code}
> Will always return participants because of operator precedence.  I am not 
> sure just adding parentheses will fix the problem, though, as the original 
> code differentiated between pending and natural endpoints.
> {code}
>  int requiredParticipants = pendingEndpoints.size() + 1 + 
> naturalEndpoints.size() / 2; // See CASSANDRA-833
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7420) BATCH with multiple CAS operations should return add information which DML failed

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7420:

Labels: LWT  (was: )

> BATCH with multiple CAS operations should return add information which DML 
> failed
> -
>
> Key: CASSANDRA-7420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7420
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Priority: Major
>  Labels: LWT
>
> A {{BATCH}} like this
> {noformat}
> BEGIN BATCH
>   INSERT INTO foo (id, num) VALUES (42, 11);
>   INSERT INTO bar (id, num) VALUES (42, 11);
> APPLY BATCH;
> {noformat}
> Should not only return {{[applied]=false, id=42, num=11}} but also for 
> example the index of the failed statement in the batch. This allows better 
> error handling on the client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7929) Improve CAS propose CQL query

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7929:

Labels: LWT  (was: )

> Improve CAS propose CQL query 
> --
>
> Key: CASSANDRA-7929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7929
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.2.0 beta 1
>
> Attachments: JIRA-7929_2.0.diff, JIRA-7929_trunk.diff
>
>
> Propose stage only requires us to read the latest ballet we prepared. There 
> is no need to read an entire CQL row. 
> This will be very useful when CASSANDRA-7085 is implemented. As this improved 
> select query will always come from mem table. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6923) Fix UnsupportedOperationException on CAS timeout

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6923:

Labels: LWT  (was: )

> Fix UnsupportedOperationException on CAS timeout
> 
>
> Key: CASSANDRA-6923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6923
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.7
>
> Attachments: 6923.txt
>
>
> This is due to CASSANDRA-6595: we call blockFor() for the paxos consistency, 
> but we never added SERIAL/LOCAL_SERIAL in that method. Attaching trivial 
> patch to add it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5633:

Labels: LWT cql3  (was: cql3)

> CQL support for updating multiple rows in a partition using CAS
> ---
>
> Key: CASSANDRA-5633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5633
> Project: Cassandra
>  Issue Type: Improvement
>Affects Versions: 2.0 beta 1
>Reporter: sankalp kohli
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: LWT, cql3
>
> This is currently supported via Thrift but not via CQL. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6595) Avoid special casing received/expected counts in CAS timeout exceptions

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6595:

Labels: LWT  (was: )

> Avoid special casing received/expected counts in CAS timeout exceptions
> ---
>
> Key: CASSANDRA-6595
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6595
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Trivial
>  Labels: LWT
> Fix For: 2.0.5
>
> Attachments: 6595.txt
>
>
> For CAS, we send a few timeouts with -1 as received and expected counts, but 
> it's kind of confusing from a user perspective (meaning that it could easily 
> break user code that check those numbers just because they didn't expected a 
> negative number). Suggesting to return 0 for received and whatever we block 
> for for the CL involved for required instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5667) Change timestamps used in CAS ballot proposals to be more resilient to clock skew

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5667:

Labels: LWT  (was: )

> Change timestamps used in CAS ballot proposals to be more resilient to clock 
> skew
> -
>
> Key: CASSANDRA-5667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5667
> Project: Cassandra
>  Issue Type: Improvement
>Affects Versions: 2.0 beta 1
> Environment: n/a
>Reporter: Nick Puz
>Assignee: Jonathan Ellis
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0 beta 1
>
> Attachments: 5667.txt
>
>
> The current time is used to generate the timeuuid used for CAS ballots 
> proposals with the logic that if a newer proposal exists then the current one 
> needs to complete that and re-propose. The problem is that if a machine has 
> clock skew and drifts into the future it will propose with a large timestamp 
> (which will get accepted) but then subsequent proposals with lower (but 
> correct) timestamps will not be able to proceed. This will prevent CAS write 
> operations and also reads at serializable consistency level. 
> The work around is to initially propose with current time (current behavior) 
> but if the proposal fails due to a larger existing one re-propose (after 
> completing the existing if necessary) with the max of (currentTime, 
> mostRecent+1, proposed+1).
> Since small drift is normal between different nodes in the same datacenter 
> this can happen even if NTP is working properly and a write hits one node and 
> a subsequent serialized read hits another. In the case of NTP config issues 
> (or OS bugs with time esp around DST) the unavailability window could be much 
> larger.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5796:

Labels: LWT  (was: )

> Cqlsh should return a result in the case of a CAS INSERT/UPDATE
> ---
>
> Key: CASSANDRA-5796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Michaël Figuière
>Assignee: Aleksey Yeschenko
>Priority: Major
>  Labels: LWT
> Fix For: 2.0.1
>
> Attachments: 5796.txt
>
>
> Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for 
> regular {{INSERT/UPDATE}} statements, that is without displaying anything if 
> there were no error.
> Ideally it should display the ResultSet returned by these CAS statements as 
> defined in CASSANDRA-5619.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5788) StorageProxy#cas() doesn't order columns names correctly when querying

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5788:

Labels: LWT  (was: )

> StorageProxy#cas() doesn't order columns names correctly when querying
> --
>
> Key: CASSANDRA-5788
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5788
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 2.0 beta 1
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0 beta 2
>
> Attachments: 5788.txt
>
>
> When querying columns for CAS, we build the SortedSet with:
> {noformat}
> new NamesQueryFilter(ImmutableSortedSet.copyOf(expected.getColumnNames())
> {noformat}
> but ImmutableSortedSet.copyOf() uses the natural order of keys unless a 
> comparator is given, which is not what we want.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-9328:

Labels: LWT  (was: )

> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aaron Whiteside
>Priority: Major
>  Labels: LWT
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12043) Syncing most recent commit in CAS across replicas can cause all CAS queries in the CQL partition to fail

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-12043:
-
Labels: LWT  (was: )

> Syncing most recent commit in CAS across replicas can cause all CAS queries 
> in the CQL partition to fail
> 
>
> Key: CASSANDRA-12043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12043
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.1.15, 2.2.7, 3.0.9, 3.8
>
>
> We update the most recent commit on requiredParticipant replicas if out of 
> sync during the prepare round in beginAndRepairPaxos method. We keep doing 
> this in a loop till the requiredParticipant replicas have the same most 
> recent commit or we hit timeout. 
> Say we have 3 machines A,B and C and gc grace on the table is 10 days. We do 
> a CAS write at time 0 and it went to A and B but not to C.  C will get the 
> hint later but will not update the most recent commit in paxos table. This is 
> how CAS hints work. 
> In the paxos table whose gc_grace=0, most_recent_commit in A and B will be 
> inserted with timestamp 0 and with a TTL of 10 days. After 10 days, this 
> insert will become a tombstone at time 0 till it is compacted away since 
> gc_grace=0.
> Do a CAS read after say 1 day on the same CQL partition and this time prepare 
> phase involved A and C. most_recent_commit on C for this CQL partition is 
> empty. A sends the most_recent_commit to C with a timestamp of 0 and with a 
> TTL of 10 days. This most_recent_commit on C will expire on 11th day since it 
> is inserted after 1 day. 
> most_recent_commit are now in sync on A,B and C, however A and B 
> most_recent_commit will expire on 10th day whereas for C it will expire on 
> 11th day since it was inserted one day later. 
> Do another CAS read after 10days when most_recent_commit on A and B have 
> expired and is treated as tombstones till compacted. In this CAS read, say A 
> and C are involved in prepare phase. most_recent_commit will not match 
> between them since it is expired in A and is still there on C. This will 
> cause most_recent_commit to be applied to A with a timestamp of 0 and TTL of 
> 10 days. If A has not compacted away the original most_recent_commit which 
> has expired, this new write to most_recent_commit wont be visible on reads 
> since there is a tombstone with same timestamp(Delete wins over data with 
> same timestamp). 
> Another round of prepare will follow and again A would say it does not know 
> about most_recent_write(covered by original write which is not a tombstone) 
> and C will again try to send the write to A. This can keep going on till the 
> request timeouts or only A and B are involved in the prepare phase. 
> When A’s original most_recent_commit which is now a tombstone is compacted, 
> all the inserts which it was covering will come live. This will in turn again 
> get played to another replica. This ping pong can keep going on for a long 
> time. 
> The issue is that most_recent_commit is expiring at different times across 
> replicas. When they get replayed to a replica to make it in sync, we again 
> set the TTL from that point.  
> During the CAS read which timed out, most_recent_commit was being sent to 
> another replica in a loop. Even in successful requests, it will try to loop 
> for a couple of times if involving A and C and then when the replicas which 
> respond are A and B, it will succeed. So this will have impact on latencies 
> as well. 
> These timeouts gets worse when a machine is down as no progress can be made 
> as the machine with unexpired commit is always involved in the CAS prepare 
> round. Also with range movements, the new machine gaining range has empty 
> most recent commit and gets the commit at a later time causing same issue. 
> Repro steps:
> 1. Paxos TTL is max(3 hours, gc_grace) as defined in 
> SystemKeyspace.paxosTtl(). Change this method to not put a minimum TTL of 3 
> hours. 
> Method  SystemKeyspace.paxosTtl() will look like return 
> metadata.getGcGraceSeconds();   instead of return Math.max(3 * 3600, 
> metadata.getGcGraceSeconds());
> We are doing this so that we dont need to wait for 3 hours. 
> Create a 3 node cluster with the code change suggested above with machines 
> A,B and C
> CREATE KEYSPACE  test WITH REPLICATION = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 3 };
> use test;
> CREATE TABLE users (a int PRIMARY KEY,b int);
> alter table users WITH gc_grace_seconds=120;
> consistency QUORUM;
> bring down machine C
> INSERT INTO users (user_name, password ) VALUES ( 1,1) IF NOT EXISTS;
> Nodetool flush on machine A and B
> 

[jira] [Updated] (CASSANDRA-5442) Add support for specifying CAS commit CL

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5442:

Labels: LWT  (was: )

> Add support for specifying CAS commit CL
> 
>
> Key: CASSANDRA-5442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5442
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Major
>  Labels: LWT
> Fix For: 2.0 beta 1
>
> Attachments: 5442-rebased.txt
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7343) CAS contention back off time should be configurable

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7343:

Labels: LWT  (was: )

> CAS contention back off time should be configurable 
> 
>
> Key: CASSANDRA-7343
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7343
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.11
>
> Attachments: cas20-7343.diff, trunk-7343.diff
>
>
> We are currently making the contention call sleep for upto 100 millis. This 
> is not ideal for all situations specially if you are doing LOCAL_SERIAL. 
> This value should be configurable based on CL.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-6363) CAS not applied on rows containing an expired ttl column

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-6363:

Labels: LWT  (was: )

> CAS not applied on rows containing an expired ttl column
> 
>
> Key: CASSANDRA-6363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6363
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
> Environment: Linux/x64 2.0.2 4-node cluster
>Reporter: Michał Ziemski
>Assignee: Stefania
>Priority: Major
>  Labels: LWT
>
> CREATE TABLE session (
>   id text,
>   usr text,
>   valid int,
>   PRIMARY KEY (id)
> );
> insert into session (id, usr) values ('abc', 'abc');
> update session using ttl 1 set valid = 1 where id = 'abc';
> (wait 1 sec)
> And 
> delete from session where id = 'DSYUCTCLSOEKVLAQWNWYLVQMEQGGXD' if usr 
> ='demo';
> Yields:
>  [applied] | usr
> ---+-
>  False | abc
> Rather than applying the delete.
> Executing:
> update session set valid = null where id = 'abc';
> and again
> delete from session where id = 'DSYUCTCLSOEKVLAQWNWYLVQMEQGGXD' if usr 
> ='demo';
> Positively deletes the row.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7342) CAS writes do not have hint functionality.

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7342:

Summary: CAS writes do not have hint functionality.   (was: CAS writes does 
not have hint functionality. )

> CAS writes do not have hint functionality. 
> ---
>
> Key: CASSANDRA-7342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7342
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Major
>  Labels: LWT
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
> Attachments: 7342_2.0.txt, 7342_2.1.txt
>
>
> When a dead node comes up, it gets the last commit but not anything which it 
> has missed. 
> This reduces the durability of those writes compared to other writes. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-14087) NPE when CAS encounters empty frozen collection

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-14087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-14087:
-
Labels: LWT  (was: )

> NPE when CAS encounters empty frozen collection
> ---
>
> Key: CASSANDRA-14087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14087
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jens Bannmann
>Assignee: Kurt Greaves
>Priority: Major
>  Labels: LWT
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> When a compare-and-set operation specifying an equality criterion with a 
> non-{{null}} value encounters an empty collection ({{null}} cell), the server 
> throws a {{NullPointerException}} and the query fails.
> This does not happen for non-frozen collections.
> There's a self-contained test case at 
> [github|https://github.com/incub8/cassandra-npe-in-cas].
> The stack trace for 3.11.0 is:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-11-27 12:59:26,924 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.cql3.ColumnCondition$CollectionBound.appliesTo(ColumnCondition.java:546)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest$ColumnsConditions.appliesTo(CQL3CasRequest.java:324)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.appliesTo(CQL3CasRequest.java:210)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:265) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:217)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.0.jar:3.11.0]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7342) CAS writes does not have hint functionality.

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7342:

Labels: LWT  (was: )

> CAS writes does not have hint functionality. 
> -
>
> Key: CASSANDRA-7342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7342
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Major
>  Labels: LWT
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
> Attachments: 7342_2.0.txt, 7342_2.1.txt
>
>
> When a dead node comes up, it gets the last commit but not anything which it 
> has missed. 
> This reduces the durability of those writes compared to other writes. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13816) Document and test CAS and non-CAS batch behavior for deleting and inserting the same key

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13816:
-
Labels: LWT lhf  (was: lhf)

> Document and test CAS and non-CAS batch behavior for deleting and inserting 
> the same key
> 
>
> Key: CASSANDRA-13816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13816
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation and Website, Testing
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Minor
>  Labels: LWT, lhf
> Fix For: 3.11.x, 4.x
>
>
> Add/verify unit tests for inserting and deleting the same key for cell 
> deletion, partition deletion, and range tombstone deletion for both CAS and 
> non-CAS batches.
> Don't change the existing behavior.
> The behavior differs between batch and CAS so in the both the CAS and batch 
> documentation mention that the behavior is not consistent. Make sure it is 
> visible in both high level and reference docs for that functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7752) Fix expiring map time for CAS messages

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7752:

Labels: LWT  (was: )

> Fix expiring map time for CAS messages
> --
>
> Key: CASSANDRA-7752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7752
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
>  Labels: LWT
> Fix For: 2.0.10
>
> Attachments: trunk-7752.diff
>
>
> CAS PrepareCallback is kept in expiring map for 10 seconds which is more than 
> the timeout. I found this while analyzing a heap dump and saw a lot of Commit 
> and PrepareCallback objects referenced by expiring map. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5832) DELETE CAS on 'primary key only' table

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5832:

Labels: LWT  (was: )

> DELETE CAS on 'primary key only' table
> --
>
> Key: CASSANDRA-5832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5832
> Project: Cassandra
>  Issue Type: Improvement
>Affects Versions: 2.0 beta 2
>Reporter: Blair Zajac
>Priority: Minor
>  Labels: LWT
>
> Following up on the "CAS on 'primary key only' table" issue [1] which added 
> support for atomically creating a primary key only table, this ticket is 
> requesting support for a CAS DELETE of a row from such a table.
> Currently these two different statements fail:
> Trying "DELETE FROM test1 WHERE k = 456 IF EXISTS" using cassandra-dbapi2:
> cql.apivalues.ProgrammingError: Bad Request: line 0:-1 no viable alternative 
> at input ''
> Trying "DELETE FROM test1 WHERE k = 456 IF k = 456"
> cql.apivalues.ProgrammingError: Bad Request: PRIMARY KEY part k found in SET 
> part
> [1] https://issues.apache.org/jira/browse/CASSANDRA-5715



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5786) Thrift cas() method crashes if input columns are not sorted.

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5786:

Labels: LWT  (was: )

> Thrift cas() method crashes if input columns are not sorted.
> 
>
> Key: CASSANDRA-5786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5786
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 2.0 beta 1
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0 beta 2
>
> Attachments: 5786.txt
>
>
> CassandraServer#cas() use UnsortedColumns for the "updates", which might 
> result later to a
> {noformat}
> java.lang.AssertionError: Added column does not sort as the last column
> at 
> org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:115)
> at 
> org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:117)
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:119)
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:96)
> at 
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:91)
> at 
> org.apache.cassandra.service.paxos.Commit$CommitSerializer.deserialize(Commit.java:139)
> at 
> org.apache.cassandra.service.paxos.Commit$CommitSerializer.deserialize(Commit.java:128)
> at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
> at 
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:175)
> at 
> org.apache.cassandra.net.IncomingTcpConnection.handleModernVersion(IncomingTcpConnection.java:135)
> at 
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-7067) Refuse CAS batch that have a 'USING TIMESTAMP'

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-7067:

Labels: LWT lhf  (was: lhf)

> Refuse CAS batch that have a 'USING TIMESTAMP'
> --
>
> Key: CASSANDRA-7067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7067
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Mikhail Stepura
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: LWT, lhf
> Fix For: 2.0.9
>
> Attachments: 7067.txt
>
>
> Cassandra must refuse  BATCHes with {{TIMESTAMP}}, if they contain a CAS 
> statement(s). Like this one:
> {code}
> BEGIN BATCH USING TIMESTAMP 
> INSERT INTO users (id, firstname, lastname) VALUES (999, 'Jack', 'Sparrow')  
> IF NOT EXISTS
> APPLY BATCH
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12971) Add CAS option to WRITE test to stress tool

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-12971:
-
Labels: LWT  (was: )

> Add CAS option to WRITE test to stress tool
> ---
>
> Key: CASSANDRA-12971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12971
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Stress, Tools
>Reporter: Vovodroid
>Assignee: Vovodroid
>Priority: Major
>  Labels: LWT
> Attachments: stress-cass.patch
>
>
> If -cas option is present each UPDATE is performed with true IF condition, 
> thus data is inserted anyway.
> It's implemented, if it's needed I proceed with the patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-10329) Improve CAS testing during range movements

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-10329:
-
Labels: LWT  (was: )

> Improve CAS testing during range movements
> --
>
> Key: CASSANDRA-10329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10329
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Brandon Williams
>Assignee: Ryan McGuire
>Priority: Major
>  Labels: LWT
>
> I've heard reports of increased timeouts with CAS specifically during 
> topology changes.  Let's beef up the CAS testing during these to see if there 
> are any problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-13086) CAS resultset sometimes does not contain value column even though wasApplied is false

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-13086:
-
Labels: LWT  (was: )

> CAS resultset sometimes does not contain value column even though wasApplied 
> is false
> -
>
> Key: CASSANDRA-13086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13086
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Christian Spriegel
>Priority: Minor
>  Labels: LWT
>
> Every now and then I see a ResultSet for one of my CAS queries that contain 
> wasApplied=false, but does not contain my value column.
> I just now found another occurrence, which causes the following exception in 
> the driver:
> {code}
> ...
> Caused by: com.mycompany.MyDataaccessException: checkLock(ResultSet[ 
> exhausted: true, Columns[[applied](boolean)]])
> at com.mycompany.MyDAO._checkLock(MyDAO.java:408)
> at com.mycompany.MyDAO._releaseLock(MyDAO.java:314)
> ... 16 more
> Caused by: java.lang.IllegalArgumentException: value is not a column defined 
> in this metadata
> at 
> com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:266)
> at 
> com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:272)
> at 
> com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:81)
> at 
> com.datastax.driver.core.AbstractGettableData.getBytes(AbstractGettableData.java:151)
> at com.mycompany.MyDAO._checkLock(MyDAO.java:383)
> ... 17 more
> {code}
> The query the application was doing:
> delete from "Lock" where lockname=:lockname and id=:id if value=:value;
> I did some debugging recently and was able to track these ResultSets to 
> StorageProxy.cas() to the "CAS precondition does not match current values {}" 
> return statement.
> I saw this happening with Cassandra 3.0.10 and earlier versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5848) Write some CAS related dtests

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5848:

Labels: LWT qa-resolved  (was: qa-resolved)

> Write some CAS related dtests
> -
>
> Key: CASSANDRA-5848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5848
> Project: Cassandra
>  Issue Type: Test
>Reporter: Ryan McGuire
>Assignee: Ryan McGuire
>Priority: Major
>  Labels: LWT, qa-resolved
>
> Write some distributed tests using CAS.
> See CASSANDRA-5443 for CQL examples.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-11507) Nodetool proxyhistograms is missing CAS stats

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-11507:
-
Labels: LWT  (was: )

> Nodetool proxyhistograms is missing CAS stats
> -
>
> Key: CASSANDRA-11507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11507
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
>Priority: Minor
>  Labels: LWT
> Fix For: 3.6
>
> Attachments: 0001-Add-missing-CAS-metrics-to-proxystats.patch
>
>
> At the moment only writes/reads are shown. Attached patch adds 
> CASRead/CASWrite and ViewWrite.
> Github branch here: 
> https://github.com/chbatey/cassandra-1/tree/cas-metrics-in-proxystats



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values

2018-05-11 Thread Jeremy Hanna (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-5619:

Labels: LWT  (was: )

> CAS UPDATE for a lost race: save round trip by returning column values
> --
>
> Key: CASSANDRA-5619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5619
> Project: Cassandra
>  Issue Type: Improvement
>Affects Versions: 2.0 beta 1
>Reporter: Blair Zajac
>Assignee: Sylvain Lebresne
>Priority: Major
>  Labels: LWT
> Fix For: 2.0 beta 1
>
> Attachments: 0001-Add-back-boolean-result-column.txt, 5619.txt, 
> 5619_thrift_fixup.txt
>
>
> Looking at the new CAS CQL3 support examples [1], if one lost a race for an 
> UPDATE, to save a round trip to get the current values to decide if you need 
> to perform your work, could the columns that were used in the IF clause also 
> be returned to the caller?  Maybe the columns values as part of the SET part 
> could also be returned.
> I don't know if this is generally useful though.
> In the case of creating a new user account with a given username which is the 
> partition key, if one lost the race to another person creating an account 
> with the same username, it doesn't matter to the loser what the column values 
> are, just that they lost.
> I'm new to Cassandra, so maybe there's other use cases, such as doing 
> incremental amount of work on a row.  In pure Java projects I've done while 
> loops around AtomicReference.html#compareAndSet() until the work was done on 
> the referenced object to handle multiple threads each making forward progress 
> in updating the references object.
> [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



  1   2   >