date:20180302


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

Jim Wartnick commented on CASSANDRA-14167:
--

I am having the exact same problem. Upgraded to Cassandra 3.11.1. I have a 
reproducible case with a record.

I even tried copying the data out to a flat-file, truncating the table, and 
re-loading it back in. Then flushed the memtables and re-queried a single, 
random, record which fails with consistency LOCAL_QUORUM but works fine with 
consistency ONE OR works fine if you don't specify the column name (e.g. SELECT 
*). 

 

 

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Priority: Major
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_144]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> {code}
> Query works completely find on consistency level ONE but not on QUORUM. 
> Is this possibly related to CASSANDRA-11726?



--
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] [Commented] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention

2018-03-02 Thread Robert Stupp (JIRA)


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

Robert Stupp commented on CASSANDRA-5836:
-

Don't assume that a new cluster is empty or that it's safe to assume that the 
first ever seed node has no data. If authentication is enabled, a default user 
is created. It would be very surprising for users ("can't login with cassandra 
anymore!") and actually a real security issue, if that user is recreated (if it 
was dropped) or the password changed back to the default.

> Seed nodes should be able to bootstrap without manual intervention
> --
>
> Key: CASSANDRA-5836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bill Hathaway
>Priority: Minor
>
> The current logic doesn't allow a seed node to be bootstrapped.  If a user 
> wants to bootstrap a node configured as a seed (for example to replace a seed 
> node via replace_token), they first need to remove the node's own IP from the 
> seed list, and then start the bootstrap process.  This seems like an 
> unnecessary step since a node never uses itself as a seed.
> I think it would be a better experience if the logic was changed to allow a 
> seed node to bootstrap without manual intervention when there are other seed 
> nodes up in a ring.



--
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] [Commented] (CASSANDRA-14260) Refactor pair to avoid boxing longs/ints

2018-03-02 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-14260:
--

Had a look and this lgtm in general. I'm not super inspired naming wise right 
now though there is good suggestions by [~djoshi3] above (one thing I'd notice 
is that {{trueSize}} is weird naming in the first place, so maybe 
{{dataSizeBytes}} instead?). Happy to not nitpick too much though, this is 
clearly much better than it was before imo.

> Refactor pair to avoid boxing longs/ints
> 
>
> Key: CASSANDRA-14260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14260
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
> Fix For: 4.x
>
>
> We uses Pair all over the place, and in many cases either/both of X and 
> Y are primitives (ints, longs), and we end up boxing them into Integers and 
> Longs. We should have specialized versions that take primitives. 



--
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] [Assigned] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost

2018-03-02 Thread Jordan West (JIRA)


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

Jordan West reassigned CASSANDRA-14285:
---

Assignee: Nicolas Guyomar  (was: Jordan West)

> Comma at the end of the end of the seed list is interpretated as localhost
> --
>
> Key: CASSANDRA-14285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Marco
>Assignee: Nicolas Guyomar
>Priority: Minor
>
> Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log 
> with messages like this one.
> DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
> 15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
> localhost/[127.0.0.1|http://127.0.0.1/]
> This code provide by Nicolas Guyomar provide the reason of the issue.
> In SImpleSeedProvider : 
>  
> String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
> List seeds = new ArrayList(hosts.length);
> for (String host : hosts)
> {
> System.out.println(InetAddress.getByName(host.trim()));
> }
>  
> output : 
> /[10.1.20.10|http://10.1.20.10/]
> /[10.1.21.10|http://10.1.21.10/]
> /[10.1.22.10|http://10.1.22.10/]
> localhost/[127.0.0.1|http://127.0.0.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] [Commented] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention

2018-03-02 Thread Robert Coli (JIRA)


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

Robert Coli commented on CASSANDRA-5836:


I should probably join #cassandra-dev IRC and chat about this there, but I'd 
like to refer people to this comment up-ticket :

https://issues.apache.org/jira/browse/CASSANDRA-5836?focusedCommentId=13727032=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13727032


Nobody really seems to understand why it's not safe for a seed node to 
bootstrap, because the workaround is to temporarily pretend the node isn't a 
seed and to bootstrap it. Usually one doesn't even inform the other nodes that 
it temporarily isn't a seed, and nothing unsafe seems to happen.

I feel like clarity here starts with explaining in what cases a Seed node is 
actually "Seeding" and what "Seeding" means and does not mean. My understanding 
is that the 'seed node' role has a significant initial-topology-discovery 
responsibility which I have not seen mentioned in recent discussions. This 
dovetails with needing to understand seed node behavior in the "restoring from 
snapshot" case, where the topology is known from existing cluster information 
and therefore may or may not "need" to be discovered from a seed. Also, as of 
my last knowledge of this code, a given node will gossip with a Seed node more 
frequently than its other peers, which I believe is "just an optimization of 
gossip" but seems notable.

I also recall past dev discussion (with driftx?) suggesting that the "correct" 
solution in their view is an external seed provider.

So in summary my understanding of the complete responsibilities of a seed, 
independent from whether it's serving as a bootstrap source or bootstrapping 
itself :
#) provide other nodes which consider it a seed with initial topology

#) provide "faster" topology updates to nodes which have me listed in their 
seed provider

The minimum requirement for a new node joining the cluster seems to be a single 
seed node that can inform it of topology in a timely manner. If that's correct 
and we imagine that all nodes use a seed provider that always returns at least 
one available node that can fulfill that role, the problem (?) of not being 
able to bootstrap seed nodes seems to disappear?

> Seed nodes should be able to bootstrap without manual intervention
> --
>
> Key: CASSANDRA-5836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bill Hathaway
>Priority: Minor
>
> The current logic doesn't allow a seed node to be bootstrapped.  If a user 
> wants to bootstrap a node configured as a seed (for example to replace a seed 
> node via replace_token), they first need to remove the node's own IP from the 
> seed list, and then start the bootstrap process.  This seems like an 
> unnecessary step since a node never uses itself as a seed.
> I think it would be a better experience if the logic was changed to allow a 
> seed node to bootstrap without manual intervention when there are other seed 
> nodes up in a ring.



--
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] [Comment Edited] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention

2018-03-02 Thread Robert Coli (JIRA)


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

Robert Coli edited comment on CASSANDRA-5836 at 3/2/18 7:02 PM:


I should probably join #cassandra-dev IRC and chat about this there, but I'd 
like to refer people to this comment up-ticket :

https://issues.apache.org/jira/browse/CASSANDRA-5836?focusedCommentId=13727032=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13727032

Nobody really seems to understand why it's not safe for a seed node to 
bootstrap, because the workaround is to temporarily pretend the node isn't a 
seed and to bootstrap it. Usually one doesn't even inform the other nodes that 
it temporarily isn't a seed, and nothing unsafe seems to happen.

I feel like clarity here starts with explaining in what cases a Seed node is 
actually "Seeding" and what "Seeding" means and does not mean. My understanding 
is that the 'seed node' role has a significant initial-topology-discovery 
responsibility which I have not seen mentioned in recent discussions. This 
dovetails with needing to understand seed node behavior in the "restoring from 
snapshot" case, where the topology is known from existing cluster information 
and therefore may or may not "need" to be discovered from a seed. Also, as of 
my last knowledge of this code, a given node will gossip with a Seed node more 
frequently than its other peers, which I believe is "just an optimization of 
gossip" but seems notable.

I also recall past dev discussion (with driftx?) suggesting that the "correct" 
solution in their view is an external seed provider.

So in summary my understanding of the complete responsibilities of a seed, 
independent from whether it's serving as a bootstrap source or bootstrapping 
itself :
1) provide other nodes which consider it a seed with initial topology

2) provide "faster" topology updates to nodes which have me listed in their 
seed provider

The minimum requirement for a new node joining the cluster seems to be a single 
seed node that can inform it of topology in a timely manner. If that's correct 
and we imagine that all nodes use a seed provider that always returns at least 
one available node that can fulfill that role, the problem (?) of not being 
able to bootstrap seed nodes seems to disappear?


was (Author: rcoli):
I should probably join #cassandra-dev IRC and chat about this there, but I'd 
like to refer people to this comment up-ticket :

https://issues.apache.org/jira/browse/CASSANDRA-5836?focusedCommentId=13727032=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13727032


Nobody really seems to understand why it's not safe for a seed node to 
bootstrap, because the workaround is to temporarily pretend the node isn't a 
seed and to bootstrap it. Usually one doesn't even inform the other nodes that 
it temporarily isn't a seed, and nothing unsafe seems to happen.

I feel like clarity here starts with explaining in what cases a Seed node is 
actually "Seeding" and what "Seeding" means and does not mean. My understanding 
is that the 'seed node' role has a significant initial-topology-discovery 
responsibility which I have not seen mentioned in recent discussions. This 
dovetails with needing to understand seed node behavior in the "restoring from 
snapshot" case, where the topology is known from existing cluster information 
and therefore may or may not "need" to be discovered from a seed. Also, as of 
my last knowledge of this code, a given node will gossip with a Seed node more 
frequently than its other peers, which I believe is "just an optimization of 
gossip" but seems notable.

I also recall past dev discussion (with driftx?) suggesting that the "correct" 
solution in their view is an external seed provider.

So in summary my understanding of the complete responsibilities of a seed, 
independent from whether it's serving as a bootstrap source or bootstrapping 
itself :
#) provide other nodes which consider it a seed with initial topology

#) provide "faster" topology updates to nodes which have me listed in their 
seed provider

The minimum requirement for a new node joining the cluster seems to be a single 
seed node that can inform it of topology in a timely manner. If that's correct 
and we imagine that all nodes use a seed provider that always returns at least 
one available node that can fulfill that role, the problem (?) of not being 
able to bootstrap seed nodes seems to disappear?

> Seed nodes should be able to bootstrap without manual intervention
> --
>
> Key: CASSANDRA-5836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Bill Hathaway
>Priority: Minor
>
> The

[jira] [Comment Edited] (CASSANDRA-14167) IndexOutOfBoundsException when selecting column counter and consistency quorum


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

Jim Wartnick edited comment on CASSANDRA-14167 at 3/2/18 7:20 PM:
--

I am having the exact same problem. Upgraded to Cassandra 3.11.1. I have a 
reproducible case with a record.

I even tried copying the data out to a flat-file, truncating the table, and 
re-loading it back in. Then flushed the memtables and re-queried a single, 
random, record which fails with consistency LOCAL_QUORUM but works fine with 
consistency ONE OR works fine if you don't specify the column name (e.g. SELECT 
*). 

One workaround that worked for us - as this is NOT a production environment 
yet, was to set the RF=1 on the keyspaces that contained the "counter" tables. 
By doing that the CF of QUORUM equates to 1, which then fixes the issue (no 
read repairs or validations required). Obviously if this was production, I 
would have some concerns regarding data availability, but for now, this is a 
workaround that may work for someone else.

 


was (Author: jwartnic):
I am having the exact same problem. Upgraded to Cassandra 3.11.1. I have a 
reproducible case with a record.

I even tried copying the data out to a flat-file, truncating the table, and 
re-loading it back in. Then flushed the memtables and re-queried a single, 
random, record which fails with consistency LOCAL_QUORUM but works fine with 
consistency ONE OR works fine if you don't specify the column name (e.g. SELECT 
*). 

 

 

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Priority: Major
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_144]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> {code}
> Query works completely find on consistency level ONE but not on QUORUM. 
> Is this possibly related to CASSANDRA-11726?



--
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] [Issue Comment Deleted] (CASSANDRA-14167) IndexOutOfBoundsException when selecting column counter and consistency quorum


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

Jim Wartnick updated CASSANDRA-14167:
-
Comment: was deleted

(was: I wanted to add one more comment, to my above statement, our workaround, 
as this is NOT a production environment yet, was to set the RF=1 on the 
keyspaces that contained the "counter" tables. By doing that the CF of QUORUM = 
1, which then fixes the issue (no read repairs or validations required). 
Obviously if this was production, I would have some concerns regarding data 
availability, but for now, this is a workaround that may work for someone else.)

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Priority: Major
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_144]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> {code}
> Query works completely find on consistency level ONE but not on QUORUM. 
> Is this possibly related to CASSANDRA-11726?



--
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] [Created] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-03-02 Thread JIRA

Szymon Acedański created CASSANDRA-14286:


 Summary: IndexOutOfBoundsException with SELECT JSON using IN and 
ORDER BY
 Key: CASSANDRA-14286
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
 Project: Cassandra
  Issue Type: Bug
 Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
Reporter: Szymon Acedański
 Attachments: orderbug-traceback.txt

When running the following code:

{code}
public class CassandraJsonOrderingBug {
public static void main(String[] args) {
Session session = CassandraFactory.getSession();

session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
INT)");
try {
session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
thebug WHERE a IN (20, 100) ORDER BY b");
statement.setFetchSize(Integer.MAX_VALUE);
for (Row w: session.execute(statement)) {
System.out.println(w.toString());
}
} finally {
session.execute("DROP TABLE thebug");
}
}
}
{code}

The following exception is thrown server-side:

{noformat}
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.Collections$SingletonList.get(Collections.java:4815) 
~[na:1.8.0_151]
at 
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
~[na:1.8.0_151]
at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
{noformat}

(full traceback attached)

The accessed index is the index of the sorted column in the SELECT JSON fields 
list.
Similarly, if the select clause is changed to

SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b

then the query finishes, but the output is sorted incorrectly (by textual JSON 
representation):

{noformat}
Row[{"b": 200, "a": 100}]
Row[{"b": 30, "a": 20}]
{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] [Commented] (CASSANDRA-14167) IndexOutOfBoundsException when selecting column counter and consistency quorum


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

Jim Wartnick commented on CASSANDRA-14167:
--

I wanted to add one more comment, to my above statement, our workaround, as 
this is NOT a production environment yet, was to set the RF=1 on the keyspaces 
that contained the "counter" tables. By doing that the CF of QUORUM = 1, which 
then fixes the issue (no read repairs or validations required). Obviously if 
this was production, I would have some concerns regarding data availability, 
but for now, this is a workaround that may work for someone else.

> IndexOutOfBoundsException when selecting column counter and consistency quorum
> --
>
> Key: CASSANDRA-14167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14167
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11.1
> Ubuntu 14-04
>Reporter: Tristan Last
>Priority: Major
>
> This morning I upgraded my cluster from 3.11.0 to 3.11.1 and it appears when 
> I perform a query on a counter specifying the column name cassandra throws 
> the following exception:
> {code:java}
> WARN [ReadStage-1] 2018-01-15 10:58:30,121 
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread 
> Thread[ReadStage-1,5,main]: {}
> java.lang.IndexOutOfBoundsException: null
> java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_144]
> java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314) ~[na:1.8.0_144]
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:173)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.context.CounterContext.updateDigest(CounterContext.java:696)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractCell.digest(AbstractCell.java:126) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.AbstractRow.digest(AbstractRow.java:73) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:181)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:120) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:345) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) 
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_144]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> {code}
> Query works completely find on consistency level ONE but not on QUORUM. 
> Is this possibly related to CASSANDRA-11726?



--
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] [Commented] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost

2018-03-02 Thread Jordan West (JIRA)


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

Jordan West commented on CASSANDRA-14285:
-

+1. As an added bonus it also fixes the case where there is a double comma in 
the string. Don't see an interpretation of the config where the operator 
intended to include localhost as a seed so I think the "breaking" change is a 
good one (i.e no one should be expecting this behavior). Since its breaking, I 
guess we can ignore back porting to 3.11 – the patch doesn't apply clean 
either. 

I wanted to ask you to add a test but it looks like that will be a pain given 
how {{SimpleSeedProvider}} is currently implemented.

Branch: [https://github.com/jrwest/cassandra/tree/14285-trunk]

utests: [https://circleci.com/gh/jrwest/cassandra/37]

 

> Comma at the end of the end of the seed list is interpretated as localhost
> --
>
> Key: CASSANDRA-14285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Marco
>Priority: Minor
>
> Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log 
> with messages like this one.
> DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
> 15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
> localhost/[127.0.0.1|http://127.0.0.1/]
> This code provide by Nicolas Guyomar provide the reason of the issue.
> In SImpleSeedProvider : 
>  
> String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
> List seeds = new ArrayList(hosts.length);
> for (String host : hosts)
> {
> System.out.println(InetAddress.getByName(host.trim()));
> }
>  
> output : 
> /[10.1.20.10|http://10.1.20.10/]
> /[10.1.21.10|http://10.1.21.10/]
> /[10.1.22.10|http://10.1.22.10/]
> localhost/[127.0.0.1|http://127.0.0.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] [Assigned] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost

2018-03-02 Thread Jordan West (JIRA)


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

Jordan West reassigned CASSANDRA-14285:
---

Assignee: Jordan West

> Comma at the end of the end of the seed list is interpretated as localhost
> --
>
> Key: CASSANDRA-14285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Marco
>Assignee: Jordan West
>Priority: Minor
>
> Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log 
> with messages like this one.
> DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
> 15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
> localhost/[127.0.0.1|http://127.0.0.1/]
> This code provide by Nicolas Guyomar provide the reason of the issue.
> In SImpleSeedProvider : 
>  
> String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
> List seeds = new ArrayList(hosts.length);
> for (String host : hosts)
> {
> System.out.println(InetAddress.getByName(host.trim()));
> }
>  
> output : 
> /[10.1.20.10|http://10.1.20.10/]
> /[10.1.21.10|http://10.1.21.10/]
> /[10.1.22.10|http://10.1.22.10/]
> localhost/[127.0.0.1|http://127.0.0.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] [Commented] (CASSANDRA-13529) cassandra-stress light-weight transaction support

2018-03-02 Thread Jaydeepkumar Chovatia (JIRA)


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

Jaydeepkumar Chovatia commented on CASSANDRA-13529:
---

Hi [~jasobrown]

If you have sometime then could you please review this ticket?

Jaydeep

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

cassandra git commit: fix simple log message spelling

2018-03-02 Thread dbrosius

Repository: cassandra
Updated Branches:
  refs/heads/trunk 2dbbbc57d -> e04462537


fix simple log message spelling


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

Branch: refs/heads/trunk
Commit: e04462537cc859139f19e0c8b7be620f2d350608
Parents: 2dbbbc5
Author: Dave Brosius 
Authored: Sat Mar 3 01:26:55 2018 -0500
Committer: Dave Brosius 
Committed: Sat Mar 3 01:26:55 2018 -0500

--
 .../org/apache/cassandra/service/NativeTransportService.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e0446253/src/java/org/apache/cassandra/service/NativeTransportService.java
--
diff --git a/src/java/org/apache/cassandra/service/NativeTransportService.java 
b/src/java/org/apache/cassandra/service/NativeTransportService.java
index 42764e1..cec9b2b 100644
--- a/src/java/org/apache/cassandra/service/NativeTransportService.java
+++ b/src/java/org/apache/cassandra/service/NativeTransportService.java
@@ -187,14 +187,14 @@ public class NativeTransportService
 }
 
 /**
- * @return intend to use epoll bassed event looping
+ * @return intend to use epoll based event looping
  */
 public static boolean useEpoll()
 {
 final boolean enableEpoll = 
Boolean.parseBoolean(System.getProperty("cassandra.native.epoll.enabled", 
"true"));
 
 if (enableEpoll && !Epoll.isAvailable() && NativeLibrary.osType == 
NativeLibrary.OSType.LINUX)
-logger.warn("epoll not availble {}", Epoll.unavailabilityCause());
+logger.warn("epoll not available {}", Epoll.unavailabilityCause());
 
 return enableEpoll && Epoll.isAvailable();
 }


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

cassandra git commit: fix logging context

2018-03-02 Thread dbrosius

Repository: cassandra
Updated Branches:
  refs/heads/trunk e04462537 -> ddaaf924e


fix logging context


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

Branch: refs/heads/trunk
Commit: ddaaf924e9aea7d283385995ea8e9503504d79c5
Parents: e044625
Author: Dave Brosius 
Authored: Sat Mar 3 01:29:35 2018 -0500
Committer: Dave Brosius 
Committed: Sat Mar 3 01:29:35 2018 -0500

--
 .../org/apache/cassandra/db/ExpirationDateOverflowHandling.java   | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ddaaf924/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java
--
diff --git 
a/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java 
b/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java
index fea729f..81e3d1e 100644
--- a/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java
+++ b/src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java
@@ -25,7 +25,6 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 import org.slf4j.helpers.MessageFormatter;
 
-import org.apache.cassandra.cql3.Attributes;
 import org.apache.cassandra.db.rows.BufferCell;
 import org.apache.cassandra.db.rows.Cell;
 import org.apache.cassandra.exceptions.InvalidRequestException;
@@ -35,7 +34,7 @@ import org.apache.cassandra.utils.NoSpamLogger;
 
 public class ExpirationDateOverflowHandling
 {
-private static final Logger logger = 
LoggerFactory.getLogger(Attributes.class);
+private static final Logger logger = 
LoggerFactory.getLogger(ExpirationDateOverflowHandling.class);
 
 private static final int EXPIRATION_OVERFLOW_WARNING_INTERVAL_MINUTES = 
Integer.getInteger("cassandra.expiration_overflow_warning_interval_minutes", 5);
 


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

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

2018-03-02 Thread Joseph Lynch (JIRA)

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

Joseph Lynch commented on CASSANDRA-12151:
--

There are a lot of competing desires in this ticket, and I want to firmly +1 an
incremental approach where we get the basic interface in and start adding new
implementations or configuration options in follow up items. If I understand
the comments above we're trying to solve the following all in one ticket:
# Logging for security
# Logging for business accounting compliance (e.g. SOX).
# Logging for monetary transaction compliance (e.g. PCI).
# Logging for replay later (e.g. for correctness testing)

These require different implementations because they require different
tradeoffs, and they may not all get done in this ticket. For example,
CASSANDRA-13983 is focused on use case #4 and appears to use a highly optimized
binary format which is lower overhead but does not meet requirements for #1/2/3
and requires custom parsers (you can't just hand the file to the auditors),
whereas the patch [~vinaykumarcse] has provided I believe aims more for #1/2/3.
Generally #2/3 require guarantees of logging if a query was attempted,
regardless of it succeeded, and #2/3 generally require a lot more context than
#1/#4 do. I think it would be great if in this ticket we can commit the basic
interface and starting points of the configuration options (e.g. is it
controlled through the cassandra.yaml or table options), and we can work on
improving performance, configuration flexibility, etc in follow up tickets.

[~jasobrown] wrote:
{quote}I agree with [~djoshi3] and [~jjordan]: this functionality should really
leverage the existing behavior of FQL (CASSANDRA-13893). There is no need to
create a parallel or duplicate set of behaviors, unless it's completely
warranted - and I have heard no arguments here that it is.
{quote}
Do you think the patch creates a parallel or duplicate set of behaviors? It
provides a different query logging implementation that makes different
tradeoffs and targets a different use case, but I think everyone is agreeing
that we can unify the two behind one interface (we just have to make sure that
interface has enough query context for all use cases which might be tough as
FQL really doesn't need all the session context like user info but #1,2,3 do).

[~eanujwa] wrote:
{quote}If you are logging the exact query with all the values in case of
regular queries (not prepared), then how would logging bind values of a
prepared statement becomes a security concern?
{quote}
Generally speaking secure applications exclusively use prepared statements as
simple statements are vulnerable to injection. Also, if you're using audit
logging for PCI (or even SOX) the data in DML could easily be sensitive (e.g.
credit cards or user's names), which you probably want to avoid by default. It
could certainly be an option though.

[~spo...@gmail.com] wrote:
{quote}Usually you'll see two kind of users on production systems: privileged
users and application users. Auditing privileged users (admins or developers)
will almost always make sense, in order to be able to detect unauthorized
access and data manipulation. There's only a limited amount of statements to
log, as these will be executed manually. It also shouldn't matter which
keyspaces or tables are access by the users; he is either monitored or not.
{quote}
Doesn't the category filter adequately achieve this (you could exclude DML or
QUERY)? Do we need per user query logging when there is already per user
permissions limiting their access to the database in the first place?
{quote}However, auditing queries of application users has a very limited
security and data privacy benefit, but adds a great deal of load to the
database. Those queries will be automatically generated by the application and
there will be no way to tell if the query or statement was authorized, as you
don't know on behalf of whom it was executed. Any auditing functionality for
these operations must therefor take place at application level.
{quote}
While I agree use case #1 (security) does not require this, use cases #2 and #3
very much do. For #2 or similar you typically have to prove that only
authorized applications manipulated the database and a typical way to do that
is to produce query logs showing that only trusted application IP addresses and
specific credentials made DML statements (but QUERY is less important). For #3
the requirements are even greater, e.g. you may have to be able to prove that
user data was not exfiltrated at all, requiring auditing of QUERY statements.
Yes it's higher overhead but if you can turn it off with the category filters I
think it's fine don't you?

> Audit logging for database activity
> ---
>
> Key: CASSANDRA-12151
>

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

2018-03-02 Thread Joseph Lynch (JIRA)

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

Joseph Lynch edited comment on CASSANDRA-12151 at 3/3/18 6:50 AM:
--

was (Author: jolynch):
There are a lot of competing

cassandra git commit: Comma at the end of the seed list is interpretated as localhost

2018-03-02 Thread jasobrown

Repository: cassandra
Updated Branches:
  refs/heads/trunk 73fa27cc6 -> 2dbbbc57d


Comma at the end of the seed list is interpretated as localhost

patch by Nicolas Guyomar; reviewed by Jordan West for (CASSANDRA-14285)


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

Branch: refs/heads/trunk
Commit: 2dbbbc57dbb70886417c888e2bf8e01da78ff6ee
Parents: 73fa27c
Author: Nicolas GUYOMAR 
Authored: Fri Mar 2 12:03:26 2018 +0100
Committer: Jason Brown 
Committed: Fri Mar 2 14:31:42 2018 -0800

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/locator/SimpleSeedProvider.java | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2dbbbc57/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ae0c7b2..f52aceb 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Comma at the end of the seed list is interpretated as localhost 
(CASSANDRA-14285)
  * Refactor read executor and response resolver, abstract read repair 
(CASSANDRA-14058)
  * Add optional startup delay to wait until peers are ready (CASSANDRA-13993)
  * Add a few options to nodetool verify (CASSANDRA-14201)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2dbbbc57/src/java/org/apache/cassandra/locator/SimpleSeedProvider.java
--
diff --git a/src/java/org/apache/cassandra/locator/SimpleSeedProvider.java 
b/src/java/org/apache/cassandra/locator/SimpleSeedProvider.java
index 47401a0..fe500b4 100644
--- a/src/java/org/apache/cassandra/locator/SimpleSeedProvider.java
+++ b/src/java/org/apache/cassandra/locator/SimpleSeedProvider.java
@@ -52,7 +52,9 @@ public class SimpleSeedProvider implements SeedProvider
 {
 try
 {
-seeds.add(InetAddressAndPort.getByName(host.trim()));
+if(!host.trim().isEmpty()) {
+seeds.add(InetAddressAndPort.getByName(host.trim()));
+}
 }
 catch (UnknownHostException ex)
 {


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

[jira] [Updated] (CASSANDRA-14194) Chain commit log marker potential performance regression in batch commit mode


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

Jason Brown updated CASSANDRA-14194:

Fix Version/s: 4.x
   3.11.x
   3.0.x
   Status: Patch Available  (was: Open)

> Chain commit log marker potential performance regression in batch commit mode
> -
>
> Key: CASSANDRA-14194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14194
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Testing
>Reporter: Ariel Weisberg
>Assignee: Jason Brown
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: jstack.txt
>
>
> CASSANDRA-13987 modified how the commit log sync thread works. I noticed that 
> cql3.ViewTest and ViewBuilderTaskTest have been timing out, but only in 
> CircleCI. When I jstack in CircleCI what I see is that the commit log writer 
> thread is parked and the threads trying to append to the commit log are 
> blocked waiting on it.
> I tested the commit before 13987 and it passed in CircleCI and then I tested 
> with 13987 and it timed out. I suspect this may be a general performance 
> regression and not just a CircleCI issue.
> And this is with write barriers disabled (sync thread doesn't actually sync) 
> so it wasn't blocked in the filesystem.



--
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] [Commented] (CASSANDRA-14194) Chain commit log marker potential performance regression in batch commit mode


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

Jason Brown commented on CASSANDRA-14194:
-

OK, think I'm at the bottom of this. While trunk is the only branch that is 
flat-out failing the unit tests due to a problem (see below), 3.0 and 3.11 
utests are performing about 5-10% slower (when using batch commit log mode), 
but that 5-10% isn't enough to cause the test to timeout.
||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14194-v2-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/14194-v2-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/14194-v2-trunk]|
|[utests & 
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14194-v2-3.0]|[utests
 & 
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14194-v2-3.11]|[utests
 & 
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14194-v2-trunk]|

This patch contains a set of small, subtle changes (the same across all three 
branches):

1) The main fix - There is a race in {{AbstractCommitLogService}} where the 
{{SyncRunnable}} thread where once we determine to call sync to disk (not just 
update the headers), we set {{syncRequested}} to false *after* calling 
{{commitLog.sync(true)}}. This allows us to have a race where 
{{commitLog.sync(true)}} begins it's marking work, but another mutation comes 
in, calls {{#requestExtraSync}} (which sets {{syncRequested}} to true, and 
calls unpark), and blocks in {{Allocation#awaitDiskSync()}}. If no other 
mutations come in (like in a unit test), {{AbstractCommitLogService}} will not 
{{commitLog.sync(true)}} (and {{CommitLogSegment#syncComplete}} will not 
release the blocked mutation) until the syncIntervalNanos is met - which, due 
to the introduction of the GroupCommitLog, is now hardcoded at 1000ms. By 
moving the {{syncRequested = false}} *before* the call to 
{{commitLog.sync(true)}} we eliminate the race.

2) related to #1, right before we choose to park the thread in 
{{SyncRunnable}}, we can check if {{syncRequested}} is true, and if so, avoid 
parking. This is a race between the sync thread completing the sync, but before 
it sleeps a new mutation calls {{#requestExtraSync}} (which unparks), and that 
mutation then gets stuck when the sync thread does park. If another mutation 
comes along it will unpark the sync thread, then both mutations can proceed; 
otherwise, the first mutation is blocked. This should only affect things like 
unit tests and *very* underutilized clusters. Note: I believe we've had this 
race since CASSANDRA-10202, but I'm not completely sure.

3) Fix a correctness problem, which, fortunately, has no practical implications 
- At the end of {{CommitLogSegment#sync()}} we always call 
{{syncComplete.signalAll()}}. {{syncComplete.signalAll()}} should only be 
called when we actually msync. Thus, if {{#sync()}} is called with {{flush}} = 
false, this could be improperly signalling any waiting threads. Luckily, 
{{AbstractCommitLogService}} should never be calling {{commitLog#sync(false)}} 
when in batch mode, so there is no improper signalling. However, for soundness 
of code, I'm moving the {{syncComplete.signalAll()}} call into the {{if(flush 
|| close)}} block in {{CommitLogSegment#sync()}}.

4) {{AbstractCommitLogService#thread}} is now marked volatile. This field is 
not defined until the {{start()}} method (not the constructor), so we're not 
guaranteed visibility when the {{#requestExtraSync()}} and 
{{#awaitTermination()}} methods run. (NOTE: this field was final and defined in 
the ctor until CASSANDRA-8308, introduced c* 2.2) Admittedly, I'm not thrilled 
with putting yet another volatile on the commit log path (only in batch mode, 
in {{#requestExtraSync()}}), but ... correctness? Also, reading a volatile 
variable isn't much more expensive vs. a regulat LOAD instruction. wdyt? This 
one arguably could be backported to 2.2+, but that ticket was committed 3.5 
years ago we have haven't heard anything, so maybe just 3.0+?

> Chain commit log marker potential performance regression in batch commit mode
> -
>
> Key: CASSANDRA-14194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14194
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core, Testing
>Reporter: Ariel Weisberg
>Assignee: Jason Brown
>Priority: Major
> Attachments: jstack.txt
>
>
> CASSANDRA-13987 modified how the commit log sync thread works. I noticed that 
> cql3.ViewTest and ViewBuilderTaskTest have been timing out, but only in 
> CircleCI. When I jstack in CircleCI what I see is that the commit log writer 
> thread is parked and the threads trying to append to the commit log are 
> blocked

[jira] [Resolved] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost


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

Jason Brown resolved CASSANDRA-14285.
-
   Resolution: Fixed
Fix Version/s: 4.0

committed as sha {{2dbbbc57dbb70886417c888e2bf8e01da78ff6ee}}. Thanks, all!

> Comma at the end of the end of the seed list is interpretated as localhost
> --
>
> Key: CASSANDRA-14285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Marco
>Assignee: Nicolas Guyomar
>Priority: Minor
> Fix For: 4.0
>
>
> Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log 
> with messages like this one.
> DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
> 15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
> localhost/[127.0.0.1|http://127.0.0.1/]
> This code provide by Nicolas Guyomar provide the reason of the issue.
> In SImpleSeedProvider : 
>  
> String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
> List seeds = new ArrayList(hosts.length);
> for (String host : hosts)
> {
> System.out.println(InetAddress.getByName(host.trim()));
> }
>  
> output : 
> /[10.1.20.10|http://10.1.20.10/]
> /[10.1.21.10|http://10.1.21.10/]
> /[10.1.22.10|http://10.1.22.10/]
> localhost/[127.0.0.1|http://127.0.0.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] [Commented] (CASSANDRA-14281) LatencyMetrics performance

2018-03-02 Thread Michael Burman (JIRA)


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

Michael Burman commented on CASSANDRA-14281:


Okay, I've managed to get to the stage where contention is reduced on high-core 
items. Instead of the whole arrays, it's just one bucket now which blocks each 
thread. That might still be an issue if updates start to be really fast and 
always hit the same low-number buckets though. rescaleIfNeeded() is still using 
a single CAS for all requests, but at least on my machine it's not yet visible. 
Have to check with a larger one.

However, the next very time consuming is the long now = clock.getTime() since 
we do System.currentTimeMillis() call. I wonder if in those cases where we do 
the startTime - System.nanoTime() measurements, we could reuse the last 
nanoTime value (just make it millis) ? That additional clock.getTime() reduces 
currently performance from 23M/s to 19M/s. And at this point the binarySearch 
is starting to be a slowdown also (reducing perf from 29M -> 23M with the 
nanoTime optimization). 

> LatencyMetrics performance
> --
>
> 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
>
> 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.
> For example, for each CFS write we do first write to the CFS's metrics and 
> then to Keyspace's metrics and finally globalMetrics. The way Timer is built 
> is to maintain a Histogram and a Meter and update both when Timer is updated. 
>  The Meter then updates 4 different values (1 minute rate, 5 minute rate, 15 
> minutes rate and a counter).
> So for each CFS write we actually do 15 different counter updates. And then 
> of course maintain their states at the same time while writing. These 
> operations are very slow when combined.
> A small JMH benchmark doing an update against a single LatencyMetrics with 4 
> threads gives us around 5.2M updates / second. With the current writeLatency 
> metric (having 2 parents) we get only 1.6M updates / second. 
> I'm proposing to update this to use a small circular buffer HdrHistogram 
> implementation. We would maintain a rolling buffer with last 15 minutes of 
> histograms (30 seconds per histogram) and update the correct bucket each 
> time. When requesting metrics we would then merge requested amount of buckets 
> to a new histogram and parse results from it. This moves some of the load 
> from writing of the metrics to reading them (which is much more infrequent 
> operation), including the parent metrics. It also allows us to maintain the 
> current metrics structure - if we wish to do so.
> My prototype with this approach improves the performance to around 13.8M 
> updates/second, thus almost 9 times faster than the current approach. We also 
> maintain HdrHistogram already in the Cassandra's lib so there's no new 
> dependencies to add (java-driver also uses it). 
> FUTURE:
> This opens up some possibilities, such as replacing all dropwizard 
> Histograms/Meters with the new approach (to reduce overhead elsewhere in the 
> codebase). It would also allow us to supply downloadable histograms directly 
> from the Cassandra or store them to the disk each time a bucket is filled if 
> user wishes to monitor latency history or graph all percentiles. 
> HdrHistogram also provides the ability to "fix" these histograms with pause 
> tracking, such as GC pauses which we currently can't do (as dropwizard 
> histograms can't be merged).



--
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] [Commented] (CASSANDRA-14070) Add new method for returning list of primary/clustering key values

2018-03-02 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-14070:


[~iamaleksey] or [~bdeggleston] , either of you have an opinion on this PR? 
Seems low risk to me, but having unused convenience functions seems like we're 
opening ourselves up for API contracts that may be tough to maintain/guarantee 
in the future? 

> Add new method for returning list of primary/clustering key values
> --
>
> Key: CASSANDRA-14070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14070
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Himani Arora
>Assignee: Himani Arora
>Priority: Minor
> Fix For: 4.x
>
>
> Add a method to return a list of primary/clustering key values so that it 
> will be easier to process data. Currently, we are getting a string 
> concatenated with either colon (: ) or comma (,) which makes it quite 
> difficult to fetch one single key 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-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-03-02 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-14286:
---
Fix Version/s: 3.11.x

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Priority: Major
> Fix For: 3.11.x
>
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {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-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

2018-03-02 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-14286:
---
Component/s: CQL

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Priority: Major
> Fix For: 3.11.x
>
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {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] [Commented] (CASSANDRA-12151) Audit logging for database activity


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

Anuj Wadehra commented on CASSANDRA-12151:
--

[~vinaykumarcse] My comments are as follows:
{quote}I like the idea of keeping the auditing configurations to be simple at 
keyspace level
{quote}
I think enabling/disabling auditing should be at table level rather than 
keyspace level. Reasoning-Keyspaces are designed based on data replication 
needs rather than auditing needs. 
Thus, a keyspace k1 may have two tables with same replication needs but 
different auditing requirements e.g. t1 with sensitive data which must be 
audited and t2 with some temporary data which need not be audited. With 
keyspace level auditing, users will end up doing unnecessary auditing and 
cluttering of audit logs.
{quote}if we are managing any configurations at table level, config file might 
not be a good place, table property?
{quote}
Agree. We can have default auditing configuration for tables in cassandra.yaml 
(say enable_audit=true/false, categories=DDL,DCL etc.,extended=true/false etc.) 
and table level properties to override the default auditing options in yaml. 
This way we will not clutter cassandra.yaml with tables to be audited, there 
would not be any additional configuration file and Cassandra configuration 
files would not have any application schema awareness.
{quote}All the usecases that I see here are Auditing at the cluster or no 
auditing, but not specific to user.
{quote}
If a Cassandra role defined for an application user has limited permissions, 
you may not want to audit everything from the application and clutter the 
auditing logs. 
But If you have a single powerful application user for database, the feature 
may not be that useful as the application user may be misused and you may 
easily bypass the application and directly login to cqlsh. I dont think 
Cassandra has an authentication mechanism to identify and restrict direct login 
for specific application users/roles. In case of direct login using an 
application user, you will log the operation but will not be able to fix the 
responsibility of the operation. More thoughts?
{quote}This would be a security concern to keep the actual data in logs
{quote}
If you are logging the exact query with all the values in case of regular 
queries (not prepared), then how would logging bind values of a prepared 
statement becomes a security concern?
{quote}
If we think logging individual statement in the batch might not come for free, 
I would rather approach it differently in case of batch, we just limit it to 
log only statement types and its count or just the prepared statement ids?
{quote}
Can we only log unique query strings in a batch to restrict IO? In case of a 
batch with prepared statements and extended configuration set to true, audit 
log format could be:

Q1: INSERT INTO t1(variable1,variable2) values(?,?)
Q2: INSERT INTO t2(variable1,variable2,variable3) values(?,?,?)

Q1 [bind_value1,bind_value2]
Q2 [bind_value1,bind_value2,bind_value3]
Q1 [bind_value1,bind_value2]
Q1 [bind_value1,bind_value2]
 
If separate log statements are used, UUID may be associated with the batch 
(like it is done in your patch)
{quote}Why do you think logging CL is required? Is CL adding any value for the 
auditor?
{quote}
What are your thoughts on this?

 

> 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.x
>
> Attachments: 12151.txt, 
> 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

[jira] [Created] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost

2018-03-02 Thread Marco (JIRA)

Marco created CASSANDRA-14285:
-

 Summary: Comma at the end of the end of the seed list is 
interpretated as localhost
 Key: CASSANDRA-14285
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
Reporter: Marco


Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log with 
messages like this one.

DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
localhost/[127.0.0.1|http://127.0.0.1/]

This code provide by Nicolas Guyomar provide the reason of the issue.

In SImpleSeedProvider : 
 
String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
List seeds = new ArrayList(hosts.length);
for (String host : hosts)
{
System.out.println(InetAddress.getByName(host.trim()));
}
 
output : 
/[10.1.20.10|http://10.1.20.10/]
/[10.1.21.10|http://10.1.21.10/]
/[10.1.22.10|http://10.1.22.10/]
localhost/[127.0.0.1|http://127.0.0.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-14209) group by select queries query results differ when using select * vs select fields

2018-03-02 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer updated CASSANDRA-14209:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed in 3.11 at 515f07b5ac75b15015401e89c379b29c788ba5a3 and merged into 
trunk

> group by select queries query results differ when using select * vs select 
> fields
> -
>
> Key: CASSANDRA-14209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14209
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Digant Modha
>Assignee: Benjamin Lerer
>Priority: Minor
> Attachments: Re group by select queries.txt
>
>
> {{I get two different out with these 2 queries.  The only difference between 
> the 2 queries is that one does ‘select *’ and other does ‘select specific 
> fields’ without any aggregate functions.}}
> {{I am using Apache Cassandra 3.10.}}
> {{Consistency level set to LOCAL_QUORUM.}}
> {{cassandra@cqlsh> select * from wp.position where account_id = 'user_1';}}
> {{ account_id | security_id | counter | avg_exec_price | pending_quantity | 
> quantity | transaction_id | update_time}}
> {{+-+-++--+--++-}}
> {{ user_1 | AMZN | 2 | 1239.2 | 0 | 1011 | null | 2018-01-25 
> 17:18:07.158000+}}
> {{ user_1 | AMZN | 1 | 1239.2 | 0 | 1010 | null | 2018-01-25 
> 17:18:07.158000+}}
> {{(2 rows)}}
> {{cassandra@cqlsh> select * from wp.position where account_id = 'user_1' 
> group by security_id;}}
> {{ account_id | security_id | counter | avg_exec_price | pending_quantity | 
> quantity | transaction_id | update_time}}
> {{+-+-++--+--++-}}
> {{ user_1 | AMZN | 1 | 1239.2 | 0 | 1010 | null | 2018-01-25 
> 17:18:07.158000+}}
> {{(1 rows)}}
> {{cassandra@cqlsh> select account_id,security_id, counter, 
> avg_exec_price,quantity, update_time from wp.position where account_id = 
> 'user_1' group by security_id ;}}
> {{ account_id | security_id | counter | avg_exec_price | quantity | 
> update_time}}
> {{+-+-++--+-}}
> {{ user_1 | AMZN | 2 | 1239.2 | 1011 | 2018-01-25 17:18:07.158000+}}
> {{(1 rows)}}
> {{Table Description:}}
> {{CREATE TABLE wp.position (}}
> {{ account_id text,}}
> {{ security_id text,}}
> {{ counter bigint,}}
> {{ avg_exec_price double,}}
> {{ pending_quantity double,}}
> {{ quantity double,}}
> {{ transaction_id uuid,}}
> {{ update_time timestamp,}}
> {{ PRIMARY KEY (account_id, security_id, counter)}}
> {{) WITH CLUSTERING ORDER BY (security_id ASC, counter DESC)}}{{ }}



--
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] [Commented] (CASSANDRA-14285) Comma at the end of the end of the seed list is interpretated as localhost

2018-03-02 Thread Nicolas Guyomar (JIRA)


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

Nicolas Guyomar commented on CASSANDRA-14285:
-

Could this one be added to Cassandra ? 
[https://github.com/nicolasguyomar/cassandra/commit/0cb5cb565c84a49ed08b216bb2a0e75ec1d2fa2c]

First small contribution

> Comma at the end of the end of the seed list is interpretated as localhost
> --
>
> Key: CASSANDRA-14285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14285
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Marco
>Priority: Minor
>
> Seeds: '10.1.20.10,10.1.21.10,10.1.22.10,'  cause a flood of the debug log 
> with messages like this one.
> DEBUG [MessagingService-Outgoing-localhost/127.0.0.1-Gossip] 2018-02-28 
> 15:53:57,314 OutboundTcpConnection.java:545 - Unable to connect to 
> localhost/[127.0.0.1|http://127.0.0.1/]
> This code provide by Nicolas Guyomar provide the reason of the issue.
> In SImpleSeedProvider : 
>  
> String[] hosts = "10.1.20.10,10.1.21.10,10.1.22.10,".split(",", -1);
> List seeds = new ArrayList(hosts.length);
> for (String host : hosts)
> {
> System.out.println(InetAddress.getByName(host.trim()));
> }
>  
> output : 
> /[10.1.20.10|http://10.1.20.10/]
> /[10.1.21.10|http://10.1.21.10/]
> /[10.1.22.10|http://10.1.22.10/]
> localhost/[127.0.0.1|http://127.0.0.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-14205) ReservedKeywords class is missing some reserved CQL keywords

2018-03-02 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer updated CASSANDRA-14205:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

> ReservedKeywords class is missing some reserved CQL keywords
> 
>
> Key: CASSANDRA-14205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14205
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Major
> Fix For: 3.11.x, 4.x
>
>
> The CQL keywords {{DEFAULT}}, {{UNSET}}, {{MBEAN}} and {{MBEANS}} (introduced 
> by CASSANDRA-11424 and CASSANDRA-10091) are neither considered [unreserved 
> keywords|https://github.com/apache/cassandra/blob/trunk/src/antlr/Parser.g#L1788-L1846]
>  by the ANTLR parser, nor included in the 
> [{{ReservedKeywords}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/ReservedKeywords.java]
>  class.
> The current parser behaviour is considering them as reserved keywords, in the 
> sense that they can't be used as keyspace/table/column names, which seems 
> right:
> {code:java}
> cassandra@cqlsh> CREATE KEYSPACE unset WITH replication = {'class': 
> 'SimpleStrategy', 'replication_factor': 1};
> SyntaxException: line 1:16 no viable alternative at input 'unset' (CREATE 
> KEYSPACE [unset]...)
> {code}
> I think we should keep considering these keywords as reserved and add them to 
> {{ReservedKeywords}} class.



--
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] [Commented] (CASSANDRA-12151) Audit logging for database activity

2018-03-02 Thread Stefan Podkowinski (JIRA)

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

Stefan Podkowinski commented on CASSANDRA-12151:

[~vinaykumarcse] wrote:

bq. Seems like a complicated configuration, would like to understand the use 
cases more here and see if anyone else needs this functionality. All the 
usecases that I see here are Auditing at the cluster or no auditing, but not 
specific to user. I would love to hear if there are any other users with this 
usecase.

Usually you'll see two kind of users on production systems: privileged users 
and application users. Auditing privileged users (admins or developers) will 
almost always make sense, in order to be able to detect unauthorized access and 
data manipulation. There's only a limited amount of statements to log, as these 
will be executed manually. It also shouldn't matter which keyspaces or tables 
are access by the users; he is either monitored or not.

However, auditing queries of application users has a very limited security and 
data privacy benefit, but adds a great deal of load to the database. Those 
queries will be automatically generated by the application and there will be no 
way to tell if the query or statement was authorized, as you don't know on 
behalf of whom it was executed. Any auditing functionality for these operations 
must therefor take place at application level. Eg. a help desk tool, which is 
used by a support employee to access personal data of a customer in Cassandra, 
must keep an activity log for that directly. It doesn't make sense to log 
queries for the generic help desk tool Cassandra user on the database side. 
Therefor we need a way to enable CQL query auditing on user level.

> 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.x
>
> Attachments: 12151.txt, 
> 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

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


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

Jason Brown commented on CASSANDRA-12151:
-

I agree with [~djoshi3] and [~jjordan]: this functionality should really 
leverage the existing behavior of FQL (CASSANDRA-13893). There is no need to 
create a parallel or duplicate set of behaviors, unless it's completely 
warranted - and I have heard no arguments here that it is.

Further, I like [~djoshi3]'s idea about adding a pluggable component that we 
can fit into the client-facing netty pipeline. It allows somebody to go bananas 
adding audit checks/details, and yet leaves untouched the standard behavior 
that 99.9% of users expect.

> 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.x
>
> Attachments: 12151.txt, 
> 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

[jira] [Commented] (CASSANDRA-14128) Prune dead links from cassandra.apache.org

2018-03-02 Thread Kenneth Brotman (JIRA)


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

Kenneth Brotman commented on CASSANDRA-14128:
-

Dead links remain.  The home page is really bad.  This is substandard.  Lots of 
bad links on home page.  Shouldn't the home page be a priority.  Ready for some 
pain!  I am.  We'll knock it out Kurt.  What's the plan going to be for the 
home page links now.  We have to make new version and submit to the group I 
think. 

> Prune dead links from cassandra.apache.org
> --
>
> Key: CASSANDRA-14128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14128
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: Jeff Jirsa
>Assignee: Kurt Greaves
>Priority: Trivial
>  Labels: lhf
> Attachments: 14128-site.patch
>
>
> Lots of dead links on the site, including the homepage. Should do some 
> pruning cleanup.
> Site repo is [here|https://svn.apache.org/repos/asf/cassandra/site/] (in svn) 
> for anyone who wishes to give this a shot.



--
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-14170) Loss of digits when doing CAST from varint/bigint to decimal

2018-03-02 Thread JIRA


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

Andrés de la Peña updated CASSANDRA-14170:
--
Reviewer: Andrés de la Peña

> Loss of digits when doing CAST from varint/bigint to decimal
> 
>
> Key: CASSANDRA-14170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14170
> Project: Cassandra
>  Issue Type: Bug
> Environment: Tested with Cassandra 3.11.1 but this issue is present 
> since the implementation of cast functions.
>Reporter: Daniel Fiala
>Assignee: Benjamin Lerer
>Priority: Minor
>
> Cast functions from numeric types to decimal type are implemented as 
> conversion to double first and then from double to decimal: 
> [https://github.com/apache/cassandra/compare/trunk...blerer:10310-3.0#diff-6aa4a8f76df6c30c5bb4026b8c9251eeR80].
> This can cause loss of digits for big values stored in varint or bigint. It 
> is probably unexpected because decimal can store such values precisely.
> Examples:
> {{cqlsh> CREATE TABLE cast_bigint_test(k int PRIMARY KEY, bigint_clmn 
> bigint);}}
>  {{cqlsh> INSERT INTO cast_bigint_test(k, decimal_clmn) VALUES(2, 
> 9223372036854775807);}}
>  {{cqlsh> SELECT CAST(bigint_clmn AS decimal) FROM cast_bigint_test;}}
>  {{cast(bigint_clmn as decimal)}}
>  {{--}}
>  {{9.223372036854776E+18}}
>  {{(1 rows)}}
> {{cqlsh> CREATE TABLE cast_varint_test (k int PRIMARY KEY, varint_clmn 
> varint);}}
>  {{cqlsh> INSERT INTO cast_varint_test(k, varint_clmn) values(2, 
> 1234567890123456789);}}
>  {{cqlsh> SELECT CAST(varint_clmn AS decimal) FROM cast_varint_test;}}
>  {{cast(varint_clmn as decimal)}}
>  {{--}}
> 1.23456789012345677E+18
>  {{(1 rows)}}
>  



--
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] [Commented] (CASSANDRA-12151) Audit logging for database activity


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

Anuj Wadehra commented on CASSANDRA-12151:
--

[~spo...@gmail.com] My comments:
{quote}Any auditing functionality for these operations must therefor take place 
at application level.
{quote}
If auditing for a database application user is only at application level, what 
would happen in case direct queries are executed on the database using the the 
application user credentials (using tools such as cqlsh)?

> 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.x
>
> Attachments: 12151.txt, 
> 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

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


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

Anuj Wadehra commented on CASSANDRA-12151:
--

[~djoshi3] Can you review the design in detail and close open points?

> 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.x
>
> Attachments: 12151.txt, 
> 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

[jira] [Issue Comment Deleted] (CASSANDRA-12151) Audit logging for database activity


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

Anuj Wadehra updated CASSANDRA-12151:
-
Comment: was deleted

(was: [~djoshi3] Can you review the design in detail and close open points?)

> 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.x
>
> Attachments: 12151.txt, 
> 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

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