[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682282#comment-13682282
]
Rick Shaw commented on CASSANDRA-4495:
--
Can't you just move the {{validate()}} method in the classes in {{o.a.c.types}}
from the ones on {{o.a.c.db.marshal}}? Then the collections classes in
{{o.a.c.types}} will have access to them.
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Carl Yeksigian
Priority: Minor
Fix For: 2.0
Attachments: 4495.patch
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5635) ThriftServer.stop() hangs forever
Robert Stupp created CASSANDRA-5635:
---
Summary: ThriftServer.stop() hangs forever
Key: CASSANDRA-5635
URL: https://issues.apache.org/jira/browse/CASSANDRA-5635
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Robert Stupp
I've written a very small main() method just to start to test how to embed
Cassandra. But the code hangs while executing CassandraDaemon.stop()...
I've used a default {{cassandra.yaml}} file.
{noformat}
cassandraDaemon = new CassandraDaemon();
cassandraDaemon.init(null);
cassandraDaemon.start();
cassandraDaemon.stop();
{noformat}
{{CassandraDaemon.stop()}} calls {{ThriftServer.stop()}, which ends somehow in
{{TCustomServerSocket.close()}}, which sets its field {{serverSocket=null}}.
This causes {{CustomTThreadPoolServer.server()}} to loop forever, because it's
{{stopped}} field is still {{false}} - {{TServerTransport.accept()}} immediatly
throws a {{TTransportException}} because {{TCustomServerSocket}}'s
{{serverSocket}} is {{null}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682450#comment-13682450
]
Aleksey Yeschenko commented on CASSANDRA-5633:
--
We only support updating several rows using BATCH in cql3, so this would
somehow involve BATCH as well.
Maybe some new kind of BATCH, CAS BATCH?
{noformat}
BEGIN CAS BATCH
UPDATE foo SET x = 10 WHERE bar = 1 AND baz = 'k' IF x = 9
UPDATE foo SET y = 15 WHERE bar = 1 AND baz = 'y' IF y = 7
DELETE FROM foo WHERE bar = 1 AND baz = 'z' IF NOT EXISTS
APPLY BATCH
{noformat}
We'll validate the partition key is the same (bar) and merge all the conditions
together (all the updates, too) and it will only apply if all the conditions
are true.
Not all statements even have to involve CAS, but at least one should.
It's not perfect, just the first thing that came to mind.
CQL support for updating multiple rows in a partition using CAS
---
Key: CASSANDRA-5633
URL: https://issues.apache.org/jira/browse/CASSANDRA-5633
Project: Cassandra
Issue Type: Improvement
Affects Versions: 2.0
Reporter: sankalp kohli
Priority: Minor
Labels: cql3
Fix For: 2.0
This is currently supported via Thrift but not via CQL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682496#comment-13682496
]
Jonathan Ellis commented on CASSANDRA-5633:
---
How about this?
{code}
UPDATE foo SET x = 10 WHERE bar = 1
IF (SELECT y FROM foo WHERE baz = 2) = 3
{code}
Pro:
# Good match with semantics of what CAS actually does under the hood
# Fairly natural for SQL users
Con:
# Need to invent syntax for multiple columns ({{IF (SELECT y, z ...) = (3, 4)}})
# Risks confusing people who wonder why we don't support subqueries elsewhere
CQL support for updating multiple rows in a partition using CAS
---
Key: CASSANDRA-5633
URL: https://issues.apache.org/jira/browse/CASSANDRA-5633
Project: Cassandra
Issue Type: Improvement
Affects Versions: 2.0
Reporter: sankalp kohli
Priority: Minor
Labels: cql3
Fix For: 2.0
This is currently supported via Thrift but not via CQL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682496#comment-13682496
]
Jonathan Ellis edited comment on CASSANDRA-5633 at 6/13/13 6:16 PM:
How about this?
{code}
UPDATE foo SET x = 10 WHERE partition='key' AND bar=1
IF (SELECT y FROM foo WHERE partition='key' AND baz = 2) = 3
{code}
Pro:
# Good match with semantics of what CAS actually does under the hood
# Fairly natural for SQL users
Con:
# Need to invent syntax for multiple columns ({{IF (SELECT y, z ...) = (3, 4)}})
# Risks confusing people who wonder why we don't support subqueries elsewhere
# Not necessarily obvious that subquery is restricted to the same partition
was (Author: jbellis):
How about this?
{code}
UPDATE foo SET x = 10 WHERE bar = 1
IF (SELECT y FROM foo WHERE baz = 2) = 3
{code}
Pro:
# Good match with semantics of what CAS actually does under the hood
# Fairly natural for SQL users
Con:
# Need to invent syntax for multiple columns ({{IF (SELECT y, z ...) = (3, 4)}})
# Risks confusing people who wonder why we don't support subqueries elsewhere
CQL support for updating multiple rows in a partition using CAS
---
Key: CASSANDRA-5633
URL: https://issues.apache.org/jira/browse/CASSANDRA-5633
Project: Cassandra
Issue Type: Improvement
Affects Versions: 2.0
Reporter: sankalp kohli
Priority: Minor
Labels: cql3
Fix For: 2.0
This is currently supported via Thrift but not via CQL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682505#comment-13682505 ] Aleksey Yeschenko commented on CASSANDRA-5633: -- I like this even less :( Maybe we shouldn't expose it to cql at all, if it doesn't fit the language? CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682515#comment-13682515 ] Jonathan Ellis commented on CASSANDRA-5633: --- Well, given that we have someone who's pretty likely to go live with this in Thrift, and we tell people that CQL exposes everything you can do from Thrift, I don't like that solution either. :) CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5630) config option to allow GossipingPropertyFileSnitch to use the reconnect trick
[ https://issues.apache.org/jira/browse/CASSANDRA-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5630: -- Reviewer: brandon.williams Priority: Minor (was: Major) config option to allow GossipingPropertyFileSnitch to use the reconnect trick --- Key: CASSANDRA-5630 URL: https://issues.apache.org/jira/browse/CASSANDRA-5630 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.5 Reporter: Chris Burroughs Assignee: Chris Burroughs Priority: Minor Fix For: 1.2.6 Attachments: CASSANDRA-5630-v1.patch Currently we have two instances of the use the local ip inside the same datacenter trick: * Ec2MultiRegionSnitch -- which is obviously EC2 specific * YamlFileNetworkTopologySnitch -- which is powerful but verbose There is no reason that GossipingPropertyFileSnitch could not (optionally) do the same. Attached is a patch that adds a preferLocal (default==false==current-behavior) property to GossipingPropertyFileSnitch and does the IEndpointStateChangeSubscriber reconnect dance. I based it on the other snitches but admit that they still seem fairly magical to me. This could be a new class that extends GossipingPropertyFileSnitch, but I could not think of a name that wasn't absurdly long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5630) config option to allow GossipingPropertyFileSnitch to use the reconnect trick
[ https://issues.apache.org/jira/browse/CASSANDRA-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5630: -- Affects Version/s: (was: 1.2.5) 1.1.1 config option to allow GossipingPropertyFileSnitch to use the reconnect trick --- Key: CASSANDRA-5630 URL: https://issues.apache.org/jira/browse/CASSANDRA-5630 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.1 Reporter: Chris Burroughs Assignee: Chris Burroughs Priority: Minor Fix For: 1.2.6 Attachments: CASSANDRA-5630-v1.patch Currently we have two instances of the use the local ip inside the same datacenter trick: * Ec2MultiRegionSnitch -- which is obviously EC2 specific * YamlFileNetworkTopologySnitch -- which is powerful but verbose There is no reason that GossipingPropertyFileSnitch could not (optionally) do the same. Attached is a patch that adds a preferLocal (default==false==current-behavior) property to GossipingPropertyFileSnitch and does the IEndpointStateChangeSubscriber reconnect dance. I based it on the other snitches but admit that they still seem fairly magical to me. This could be a new class that extends GossipingPropertyFileSnitch, but I could not think of a name that wasn't absurdly long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5631) NPE when creating column family shortly after multinode startup
[
https://issues.apache.org/jira/browse/CASSANDRA-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682624#comment-13682624
]
Martin Serrano commented on CASSANDRA-5631:
---
I was incorrect regarding Astyanax support. I just had a classpath issue.
Anyway, I have tested in 1.2.5 and can no longer reproduce. Thanks!
NPE when creating column family shortly after multinode startup
---
Key: CASSANDRA-5631
URL: https://issues.apache.org/jira/browse/CASSANDRA-5631
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Martin Serrano
I'm testing a 2-node cluster and creating a column family right after the
nodes startup. I am using the Astyanax client. Sometimes column family
creation fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-5631) NPE when creating column family shortly after multinode startup
[
https://issues.apache.org/jira/browse/CASSANDRA-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5631.
---
Resolution: Cannot Reproduce
Great; thanks for the followup!
NPE when creating column family shortly after multinode startup
---
Key: CASSANDRA-5631
URL: https://issues.apache.org/jira/browse/CASSANDRA-5631
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Martin Serrano
I'm testing a 2-node cluster and creating a column family right after the
nodes startup. I am using the Astyanax client. Sometimes column family
creation fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682720#comment-13682720 ] Jonathan Ellis commented on CASSANDRA-5633: --- bq. Maybe some new kind of BATCH, CAS BATCH? I don't see how this solves the problem of I want to CAS row X based on the value of row Y. Your example looks more like 3 separate operations each of which has CAS-in-same-row. CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5636) Add row count to select output a la psql
Jonathan Ellis created CASSANDRA-5636:
-
Summary: Add row count to select output a la psql
Key: CASSANDRA-5636
URL: https://issues.apache.org/jira/browse/CASSANDRA-5636
Project: Cassandra
Issue Type: New Feature
Components: Tools
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.2.6
This is handy since counting rows that look mostly alike can be painful; it
also makes it clear that cqlsh isn't ignoring you when you select something
that doesn't exist.
Here is what psql does:
{noformat}
company= select fname, salary from employee;
fname | salary
+
John|3.00
Franklin|4.00
Alica |25000.00
Jennifer|43000.00
Ramish |38000.00
Joyce |25000.00
Ahmad |25000.00
James |55000.00
(8 rows)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682733#comment-13682733 ] Aleksey Yeschenko commented on CASSANDRA-5633: -- bq. I don't see how this solves the problem of I want to CAS row X based on the value of row Y. Your example looks more like 3 separate operations each of which has CAS-in-same-row. True. But to match thrift api you are going to need both the ability to update several rows in a single cas operation *and* the ability to refer to other rows within the same partition in conditions. CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682755#comment-13682755 ] Jonathan Ellis commented on CASSANDRA-5633: --- Agreed, although I only have a specific use case for the latter. CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682756#comment-13682756
]
Jonathan Ellis commented on CASSANDRA-5633:
---
I submit that a more regular extention of batch for the former would be
{code}
BEGIN BATCH
UPDATE FOO ...
UPDATE FOO ...
APPLY BATCH IF ...
{code}
CQL support for updating multiple rows in a partition using CAS
---
Key: CASSANDRA-5633
URL: https://issues.apache.org/jira/browse/CASSANDRA-5633
Project: Cassandra
Issue Type: Improvement
Affects Versions: 2.0
Reporter: sankalp kohli
Priority: Minor
Labels: cql3
Fix For: 2.0
This is currently supported via Thrift but not via CQL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682766#comment-13682766 ] Aleksey Yeschenko commented on CASSANDRA-5633: -- This looks all right with '...', but specifying multiple conditions here is going to be truly verbose with IF (SELECT ...) = ... AND ... CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682770#comment-13682770 ] Jonathan Ellis commented on CASSANDRA-5633: --- Well, that's the point -- you only get one condition w/ CAS so that should be explicit in the syntax. CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5622) Update CqlRecordWriter to conform to RecordWriter API
[
https://issues.apache.org/jira/browse/CASSANDRA-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682765#comment-13682765
]
Alex Liu commented on CASSANDRA-5622:
-
I will disable INSERT query, only allow UPDATE or DELETE statement.
Update CqlRecordWriter to conform to RecordWriter API
-
Key: CASSANDRA-5622
URL: https://issues.apache.org/jira/browse/CASSANDRA-5622
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Jonathan Ellis
Assignee: Alex Liu
Fix For: 1.2.6
Attachments: 5622-1-1.2-branch.txt, 5622-1-trunk.txt
{{RecordWriterK, V}} is supposed to write values V that can be uniquely
identified by keys K.
Currently CqlRW requires the user to give it all the bind variables for a
complete statement in V, and effectively ignores K.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4718) More-efficient ExecutorService for improved throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682777#comment-13682777 ] Pavel Yaskevich commented on CASSANDRA-4718: I think even though we aren't in the most cache friendly behavior with variable size RMs we can still utilize better dispatch behavior with low cost synchronization. We can't do anything about blocking I/O operations requiring separate thread but I think it's time to re-evaluate NIO async sockets vs. having thread per in/out connection. More-efficient ExecutorService for improved throughput -- Key: CASSANDRA-4718 URL: https://issues.apache.org/jira/browse/CASSANDRA-4718 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Priority: Minor Attachments: baq vs trunk.png, PerThreadQueue.java Currently all our execution stages dequeue tasks one at a time. This can result in contention between producers and consumers (although we do our best to minimize this by using LinkedBlockingQueue). One approach to mitigating this would be to make consumer threads do more work in bulk instead of just one task per dequeue. (Producer threads tend to be single-task oriented by nature, so I don't see an equivalent opportunity there.) BlockingQueue has a drainTo(collection, int) method that would be perfect for this. However, no ExecutorService in the jdk supports using drainTo, nor could I google one. What I would like to do here is create just such a beast and wire it into (at least) the write and read stages. (Other possible candidates for such an optimization, such as the CommitLog and OutboundTCPConnection, are not ExecutorService-based and will need to be one-offs.) AbstractExecutorService may be useful. The implementations of ICommitLogExecutorService may also be useful. (Despite the name these are not actual ExecutorServices, although they share the most important properties of one.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4718) More-efficient ExecutorService for improved throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682785#comment-13682785 ] Jonathan Ellis commented on CASSANDRA-4718: --- Sounds like a reasonable place to start. More-efficient ExecutorService for improved throughput -- Key: CASSANDRA-4718 URL: https://issues.apache.org/jira/browse/CASSANDRA-4718 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Priority: Minor Attachments: baq vs trunk.png, PerThreadQueue.java Currently all our execution stages dequeue tasks one at a time. This can result in contention between producers and consumers (although we do our best to minimize this by using LinkedBlockingQueue). One approach to mitigating this would be to make consumer threads do more work in bulk instead of just one task per dequeue. (Producer threads tend to be single-task oriented by nature, so I don't see an equivalent opportunity there.) BlockingQueue has a drainTo(collection, int) method that would be perfect for this. However, no ExecutorService in the jdk supports using drainTo, nor could I google one. What I would like to do here is create just such a beast and wire it into (at least) the write and read stages. (Other possible candidates for such an optimization, such as the CommitLog and OutboundTCPConnection, are not ExecutorService-based and will need to be one-offs.) AbstractExecutorService may be useful. The implementations of ICommitLogExecutorService may also be useful. (Despite the name these are not actual ExecutorServices, although they share the most important properties of one.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5637) sstableloader does not seem to load all the data present in the provided stables
Vishy Kasar created CASSANDRA-5637: -- Summary: sstableloader does not seem to load all the data present in the provided stables Key: CASSANDRA-5637 URL: https://issues.apache.org/jira/browse/CASSANDRA-5637 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.10 Reporter: Vishy Kasar Attachments: sstable-loader-log.txt I loaded about 1 million records in to my local cassandra. I then attempted to load these records using the sstableloader to prod cassandra using command sstableloader -v -u xyz -pw abc -d st11p02me-hpbb050130-i6 /tmp/prod_p02/containers When I read back the production data later, I do not find some rows that I inserted above. Few other rows are present though. Are there known bugs in sstableloader? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5637) sstableloader does not seem to load all the data present in the provided stables
[ https://issues.apache.org/jira/browse/CASSANDRA-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishy Kasar updated CASSANDRA-5637: --- Attachment: sstable-loader-log.txt Attached the verbose logs from sstableloader command. sstableloader does not seem to load all the data present in the provided stables Key: CASSANDRA-5637 URL: https://issues.apache.org/jira/browse/CASSANDRA-5637 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.10 Reporter: Vishy Kasar Attachments: sstable-loader-log.txt I loaded about 1 million records in to my local cassandra. I then attempted to load these records using the sstableloader to prod cassandra using command sstableloader -v -u xyz -pw abc -d st11p02me-hpbb050130-i6 /tmp/prod_p02/containers When I read back the production data later, I do not find some rows that I inserted above. Few other rows are present though. Are there known bugs in sstableloader? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5632) Cross-DC bandwidth-saving broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682842#comment-13682842
]
Hayato Shimizu commented on CASSANDRA-5632:
---
Tested and fixed the issue.
Cross-DC bandwidth-saving broken
Key: CASSANDRA-5632
URL: https://issues.apache.org/jira/browse/CASSANDRA-5632
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 1.2.6
Attachments: 5632.txt
We group messages by destination as follows to avoid sending multiple
messages to a remote datacenter:
{code}
// Multimap that holds onto all the messages and addresses meant for
a specific datacenter
MapString, MultimapMessage, InetAddress dcMessages
{code}
When we cleaned out the MessageProducer stuff for 2.0, this code
{code}
MultimapMessage, InetAddress messages =
dcMessages.get(dc);
...
messages.put(producer.getMessage(Gossiper.instance.getVersion(destination)),
destination);
{code}
turned into
{code}
MultimapMessageOut, InetAddress messages =
dcMessages.get(dc);
...
messages.put(rm.createMessage(), destination);
{code}
Thus, we weren't actually grouping anything anymore -- each destination
replica was stored under a separate Message key, unlike under the old
CachingMessageProducer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5637) sstableloader does not seem to load all the data present in the provided sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishy Kasar updated CASSANDRA-5637: --- Summary: sstableloader does not seem to load all the data present in the provided sstables (was: sstableloader does not seem to load all the data present in the provided stables) sstableloader does not seem to load all the data present in the provided sstables - Key: CASSANDRA-5637 URL: https://issues.apache.org/jira/browse/CASSANDRA-5637 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.10 Reporter: Vishy Kasar Attachments: sstable-loader-log.txt I loaded about 1 million records in to my local cassandra. I then attempted to load these records using the sstableloader to prod cassandra using command sstableloader -v -u xyz -pw abc -d st11p02me-hpbb050130-i6 /tmp/prod_p02/containers When I read back the production data later, I do not find some rows that I inserted above. Few other rows are present though. Are there known bugs in sstableloader? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0f09cc5a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0f09cc5a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0f09cc5a Branch: refs/heads/trunk Commit: 0f09cc5a1b596c93bb7cbdb324391fac17892ed4 Parents: 60bf7a5 f51c962 Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jun 13 19:22:54 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jun 13 19:22:54 2013 -0500 -- bin/cassandra-shuffle | 0 1 file changed, 0 insertions(+), 0 deletions(-) --
[1/3] git commit: Make shuffle +x
Updated Branches: refs/heads/cassandra-1.2 01d4f07da - f51c962ed refs/heads/trunk 60bf7a573 - 0f09cc5a1 Make shuffle +x Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f51c962e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f51c962e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f51c962e Branch: refs/heads/cassandra-1.2 Commit: f51c962ed0b564784688a6cc8dc2794210772e1f Parents: 01d4f07 Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jun 13 19:22:47 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jun 13 19:22:47 2013 -0500 -- bin/cassandra-shuffle | 0 1 file changed, 0 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f51c962e/bin/cassandra-shuffle -- diff --git a/bin/cassandra-shuffle b/bin/cassandra-shuffle old mode 100644 new mode 100755
[2/3] git commit: Make shuffle +x
Make shuffle +x Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f51c962e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f51c962e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f51c962e Branch: refs/heads/trunk Commit: f51c962ed0b564784688a6cc8dc2794210772e1f Parents: 01d4f07 Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jun 13 19:22:47 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jun 13 19:22:47 2013 -0500 -- bin/cassandra-shuffle | 0 1 file changed, 0 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f51c962e/bin/cassandra-shuffle -- diff --git a/bin/cassandra-shuffle b/bin/cassandra-shuffle old mode 100644 new mode 100755
[jira] [Commented] (CASSANDRA-5637) sstableloader does not seem to load all the data present in the provided sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683058#comment-13683058 ] Jonathan Ellis commented on CASSANDRA-5637: --- One guess: the rows you inserted had not yet been flushed. sstableloader does not seem to load all the data present in the provided sstables - Key: CASSANDRA-5637 URL: https://issues.apache.org/jira/browse/CASSANDRA-5637 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.10 Reporter: Vishy Kasar Attachments: sstable-loader-log.txt I loaded about 1 million records in to my local cassandra. I then attempted to load these records using the sstableloader to prod cassandra using command sstableloader -v -u xyz -pw abc -d st11p02me-hpbb050130-i6 /tmp/prod_p02/containers When I read back the production data later, I do not find some rows that I inserted above. Few other rows are present though. Are there known bugs in sstableloader? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5342) ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed
[ https://issues.apache.org/jira/browse/CASSANDRA-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-5342: - Assignee: Marcus Eriksson ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed Key: CASSANDRA-5342 URL: https://issues.apache.org/jira/browse/CASSANDRA-5342 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.3 Reporter: Wei Zhu Assignee: Marcus Eriksson Fix For: 1.2.6 Attachments: Screen Shot 2013-03-13 at 12.05.08 PM.png We are using LCS and have total of 38000 SSTables for one CF. During LCS, there could be over a thousand SSTable involved. All those SSTable IDs are stored in ancestors field of SSTableMetatdata for the new table. In our case, it consumes more than 1G of heap memory for those field. Put it in perspective, the ancestors consume 2 - 3 times more memory than bloomfilter (fp = 0.1 by default) in LCS. We should remove those ancestors from SSTableMetadata after the compaction is finished and the old SSTable is removed. It might be a big deal for Sized Compaction since there are small number of SSTable involved. But it consumes a lot of memory for LCS. At least, we shouldn't load those ancestors to the memory during startup if the files are removed. I would love to contribute and provide patch. Please let me know how to start. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5636) Add row count to select output a la psql
[
https://issues.apache.org/jira/browse/CASSANDRA-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-5636:
-
Attachment: 5636.txt
Add row count to select output a la psql
Key: CASSANDRA-5636
URL: https://issues.apache.org/jira/browse/CASSANDRA-5636
Project: Cassandra
Issue Type: New Feature
Components: Tools
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
Labels: cqlsh
Fix For: 1.2.6
Attachments: 5636.txt
This is handy since counting rows that look mostly alike can be painful; it
also makes it clear that cqlsh isn't ignoring you when you select something
that doesn't exist.
Here is what psql does:
{noformat}
company= select fname, salary from employee;
fname | salary
+
John|3.00
Franklin|4.00
Alica |25000.00
Jennifer|43000.00
Ramish |38000.00
Joyce |25000.00
Ahmad |25000.00
James |55000.00
(8 rows)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[1/3] git commit: make auth config a bit friendlier
Updated Branches:
refs/heads/cassandra-1.2 f51c962ed - 30b093a71
refs/heads/trunk 0f09cc5a1 - 4bdf38b5c
make auth config a bit friendlier
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/30b093a7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/30b093a7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/30b093a7
Branch: refs/heads/cassandra-1.2
Commit: 30b093a715e61fd7773ebee3a49096cf9544421f
Parents: f51c962
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 10 06:42:04 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jun 13 21:20:33 2013 -0700
--
conf/cassandra.yaml | 4 ++--
.../apache/cassandra/config/DatabaseDescriptor.java | 4 ++--
.../org/apache/cassandra/utils/FBUtilities.java | 16
3 files changed, 20 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b093a7/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 2d2b484..75ef331 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -66,7 +66,7 @@ max_hints_delivery_threads: 2
# - PasswordAuthenticator relies on username/password pairs to authenticate
# users. It keeps usernames and hashed passwords in system_auth.credentials
table.
# Please increase system_auth keyspace replication factor if you use this
authenticator.
-authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
+authenticator: AllowAllAuthenticator
# Authorization backend, implementing IAuthorizer; used to limit
access/provide permissions
# Out of the box, Cassandra provides
org.apache.cassandra.auth.{AllowAllAuthorizer,
@@ -75,7 +75,7 @@ authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
# - AllowAllAuthorizer allows any action to any user - set it to disable
authorization.
# - CassandraAuthorizer stores permissions in system_auth.permissions table.
Please
# increase system_auth keyspace replication factor if you use this
authorizer.
-authorizer: org.apache.cassandra.auth.AllowAllAuthorizer
+authorizer: AllowAllAuthorizer
# Validity period for permissions cache (fetching permissions can be an
# expensive operation depending on the authorizer, CassandraAuthorizer is
http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b093a7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index a5bfcf2..941249f 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -206,7 +206,7 @@ public class DatabaseDescriptor
/* Authentication and authorization backend, implementing
IAuthenticator and IAuthorizer */
if (conf.authenticator != null)
-authenticator = FBUtilities.construct(conf.authenticator,
authenticator);
+authenticator =
FBUtilities.newAuthenticator(conf.authenticator);
if (conf.authority != null)
{
@@ -217,7 +217,7 @@ public class DatabaseDescriptor
}
if (conf.authorizer != null)
-authorizer = FBUtilities.construct(conf.authorizer,
authorizer);
+authorizer = FBUtilities.newAuthorizer(conf.authorizer);
if (conf.internode_authenticator != null)
internodeAuthenticator =
FBUtilities.construct(conf.internode_authenticator, internode_authenticator);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b093a7/src/java/org/apache/cassandra/utils/FBUtilities.java
--
diff --git a/src/java/org/apache/cassandra/utils/FBUtilities.java
b/src/java/org/apache/cassandra/utils/FBUtilities.java
index 1f7807d..679e3df 100644
--- a/src/java/org/apache/cassandra/utils/FBUtilities.java
+++ b/src/java/org/apache/cassandra/utils/FBUtilities.java
@@ -41,6 +41,8 @@ import org.apache.commons.lang.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import org.apache.cassandra.auth.IAuthenticator;
+import org.apache.cassandra.auth.IAuthorizer;
import org.apache.cassandra.cache.IRowCacheProvider;
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.config.DatabaseDescriptor;
@@ -394,6 +396,20 @@ public class FBUtilities
return FBUtilities.construct(partitionerClassName, partitioner);
}
+public static IAuthorizer newAuthorizer(String className) throws
[2/3] git commit: make auth config a bit friendlier
make auth config a bit friendlier
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/30b093a7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/30b093a7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/30b093a7
Branch: refs/heads/trunk
Commit: 30b093a715e61fd7773ebee3a49096cf9544421f
Parents: f51c962
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 10 06:42:04 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jun 13 21:20:33 2013 -0700
--
conf/cassandra.yaml | 4 ++--
.../apache/cassandra/config/DatabaseDescriptor.java | 4 ++--
.../org/apache/cassandra/utils/FBUtilities.java | 16
3 files changed, 20 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b093a7/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 2d2b484..75ef331 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -66,7 +66,7 @@ max_hints_delivery_threads: 2
# - PasswordAuthenticator relies on username/password pairs to authenticate
# users. It keeps usernames and hashed passwords in system_auth.credentials
table.
# Please increase system_auth keyspace replication factor if you use this
authenticator.
-authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
+authenticator: AllowAllAuthenticator
# Authorization backend, implementing IAuthorizer; used to limit
access/provide permissions
# Out of the box, Cassandra provides
org.apache.cassandra.auth.{AllowAllAuthorizer,
@@ -75,7 +75,7 @@ authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
# - AllowAllAuthorizer allows any action to any user - set it to disable
authorization.
# - CassandraAuthorizer stores permissions in system_auth.permissions table.
Please
# increase system_auth keyspace replication factor if you use this
authorizer.
-authorizer: org.apache.cassandra.auth.AllowAllAuthorizer
+authorizer: AllowAllAuthorizer
# Validity period for permissions cache (fetching permissions can be an
# expensive operation depending on the authorizer, CassandraAuthorizer is
http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b093a7/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index a5bfcf2..941249f 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -206,7 +206,7 @@ public class DatabaseDescriptor
/* Authentication and authorization backend, implementing
IAuthenticator and IAuthorizer */
if (conf.authenticator != null)
-authenticator = FBUtilities.construct(conf.authenticator,
authenticator);
+authenticator =
FBUtilities.newAuthenticator(conf.authenticator);
if (conf.authority != null)
{
@@ -217,7 +217,7 @@ public class DatabaseDescriptor
}
if (conf.authorizer != null)
-authorizer = FBUtilities.construct(conf.authorizer,
authorizer);
+authorizer = FBUtilities.newAuthorizer(conf.authorizer);
if (conf.internode_authenticator != null)
internodeAuthenticator =
FBUtilities.construct(conf.internode_authenticator, internode_authenticator);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/30b093a7/src/java/org/apache/cassandra/utils/FBUtilities.java
--
diff --git a/src/java/org/apache/cassandra/utils/FBUtilities.java
b/src/java/org/apache/cassandra/utils/FBUtilities.java
index 1f7807d..679e3df 100644
--- a/src/java/org/apache/cassandra/utils/FBUtilities.java
+++ b/src/java/org/apache/cassandra/utils/FBUtilities.java
@@ -41,6 +41,8 @@ import org.apache.commons.lang.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import org.apache.cassandra.auth.IAuthenticator;
+import org.apache.cassandra.auth.IAuthorizer;
import org.apache.cassandra.cache.IRowCacheProvider;
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.config.DatabaseDescriptor;
@@ -394,6 +396,20 @@ public class FBUtilities
return FBUtilities.construct(partitionerClassName, partitioner);
}
+public static IAuthorizer newAuthorizer(String className) throws
ConfigurationException
+{
+if (!className.contains(.))
+className = org.apache.cassandra.auth. + className;
+
[3/3] git commit: merge from 1.2
merge from 1.2
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4bdf38b5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4bdf38b5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4bdf38b5
Branch: refs/heads/trunk
Commit: 4bdf38b5c2d9a9ee74e2cab7657d00c5bb783788
Parents: 0f09cc5 30b093a
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Jun 13 21:23:31 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jun 13 21:23:31 2013 -0700
--
conf/cassandra.yaml | 4 ++--
.../cassandra/config/DatabaseDescriptor.java | 4 ++--
.../org/apache/cassandra/utils/FBUtilities.java | 18 +-
3 files changed, 21 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4bdf38b5/conf/cassandra.yaml
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4bdf38b5/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --cc src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 4d6abae,941249f..a015774
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@@ -109,364 -108,405 +109,364 @@@ public class DatabaseDescripto
}
catch (Exception e)
{
-ClassLoader loader = DatabaseDescriptor.class.getClassLoader();
-url = loader.getResource(configUrl);
-if (url == null)
-throw new ConfigurationException(Cannot locate +
configUrl);
+logger.error(Fatal error during configuration loading, e);
+System.err.println(e.getMessage() + \nFatal error during
configuration loading; unable to start. See log for stacktrace.);
+System.exit(1);
}
-
-return url;
}
-static
+@VisibleForTesting
+static Config loadConfig() throws ConfigurationException
{
-if (Config.getLoadYaml())
-loadYaml();
-else
-conf = new Config();
+String loaderClass = System.getProperty(cassandra.config.loader);
+ConfigurationLoader loader = loaderClass == null
+ ? new YamlConfigurationLoader()
+ :
FBUtilities.ConfigurationLoaderconstruct(loaderClass, configuration
loading);
+return loader.loadConfig();
}
-static void loadYaml()
+
+private static void applyConfig(Config config) throws
ConfigurationException
{
-try
-{
-URL url = getStorageConfigURL();
-logger.info(Loading settings from + url);
-InputStream input;
-try
-{
-input = url.openStream();
-}
-catch (IOException e)
-{
-// getStorageConfigURL should have ruled this out
-throw new AssertionError(e);
-}
-org.yaml.snakeyaml.constructor.Constructor constructor = new
org.yaml.snakeyaml.constructor.Constructor(Config.class);
-TypeDescription seedDesc = new
TypeDescription(SeedProviderDef.class);
-seedDesc.putMapPropertyType(parameters, String.class,
String.class);
-constructor.addTypeDescription(seedDesc);
-Yaml yaml = new Yaml(new Loader(constructor));
-conf = (Config)yaml.load(input);
+conf = config;
-logger.info(Data files directories: +
Arrays.toString(conf.data_file_directories));
-logger.info(Commit log directory: + conf.commitlog_directory);
+logger.info(Data files directories: +
Arrays.toString(conf.data_file_directories));
+logger.info(Commit log directory: + conf.commitlog_directory);
-if (conf.commitlog_sync == null)
-{
-throw new ConfigurationException(Missing required directive
CommitLogSync);
-}
+if (conf.commitlog_sync == null)
+{
+throw new ConfigurationException(Missing required directive
CommitLogSync);
+}
-if (conf.commitlog_sync == Config.CommitLogSync.batch)
-{
-if (conf.commitlog_sync_batch_window_in_ms == null)
-{
-throw new ConfigurationException(Missing value for
commitlog_sync_batch_window_in_ms: Double expected.);
-}
-else if (conf.commitlog_sync_period_in_ms != null)
-{
-throw new ConfigurationException(Batch
[jira] [Created] (CASSANDRA-5638) Improve StorageProxy tracing
Jonathan Ellis created CASSANDRA-5638: - Summary: Improve StorageProxy tracing Key: CASSANDRA-5638 URL: https://issues.apache.org/jira/browse/CASSANDRA-5638 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.6 Attachments: 5638.txt Storage proxy includes some logger.trace methods that should be Tracing.trace, and more logger.trace that aren't useful. Also QueryProcessor is not consistent about logging what it is executing and should include ConsistencyLevel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5638) Improve StorageProxy tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5638: -- Attachment: 5638.txt Improve StorageProxy tracing Key: CASSANDRA-5638 URL: https://issues.apache.org/jira/browse/CASSANDRA-5638 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.6 Attachments: 5638.txt Storage proxy includes some logger.trace methods that should be Tracing.trace, and more logger.trace that aren't useful. Also QueryProcessor is not consistent about logging what it is executing and should include ConsistencyLevel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10
[
https://issues.apache.org/jira/browse/CASSANDRA-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670577#comment-13670577
]
Alex Liu edited comment on CASSANDRA-5234 at 6/14/13 5:45 AM:
--
pull @ https://github.com/alexliu68/cassandra/pull/3
Use CassandraStorage for any cql3 tables, you will have composite columns in
columns bag
Use CQL3Storage for any cql3 table.
{code}
cassandra://[username:password@]keyspace/columnfamily[?[page_size=size]
[columns=col1,col2][output_query=prepared_statement]
[where_clause=clause][split_size=size][partitioner=partitioner]]
{code}
where
page_size is the number of cql3 rows per page (the default is 1000, it's
optional)
columns is the column names for the cql3 select query, it's optional
where_clause is the user defined where clause on the indexed column, it's
optional
split_size is the number of C* rows per split which can be used to tune the
number of mappers
output_query is the prepared query for inserting data to cql3 table (replace
the = by @ and ? by #,
because Pig can't take = and ? as url parameter values)
Output row are in the following format
{code}
(((name, value), (name, value)), (value ... value), (value...value))
{code}
where the name and value tuples are key name and value pairs.
The input schema: ((name, value), (name, value), (name, value)) where keys are
in the front.
was (Author: alexliu68):
pull @ https://github.com/alexliu68/cassandra/pull/3
Use CassandraStorage for any cql3 tables, you will have composite columns in
columns bag
Use CQL3Storage for any cql3 table.
{code}
cassandra://[username:password@]keyspace/columnfamily[?[page_size=size][columns=col1,col2][output_query=prepared_statement][where_clause=clause][split_size=size]]
{code}
where page_size is the number of cql3 rows per page (the default is 1000, it's
optional)
columns is the column names for the cql3 select query, it's optional
where_clause is the user defined where clause on the indexed column, it's
optional
split_size is the number of C* rows per split which can be used to tune the
number of mappers
output_query is the prepared query for inserting data to cql3 table
The schema: ((name, value), (name, value), (name, value)) where keys are in the
front.
Table created through CQL3 are not accessble to Pig 0.10
Key: CASSANDRA-5234
URL: https://issues.apache.org/jira/browse/CASSANDRA-5234
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 1.2.1
Environment: Red hat linux 5
Reporter: Shamim Ahmed
Fix For: 1.2.2
Attachments: 5234.tx
Hi,
i have faced a bug when creating table through CQL3 and trying to load data
through pig 0.10 as follows:
java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ'
at
org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112)
at
org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615).
This effects from Simple table to table with compound key.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5639) Update CREATE CUSTOM INDEX syntax to match new CREATE INDEX syntax
Aleksey Yeschenko created CASSANDRA-5639: Summary: Update CREATE CUSTOM INDEX syntax to match new CREATE INDEX syntax Key: CASSANDRA-5639 URL: https://issues.apache.org/jira/browse/CASSANDRA-5639 Project: Cassandra Issue Type: Improvement Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Fix For: 1.2.6 CASSANDRA-5484 introduced CREATE CUSTOM INDEX syntax for custom 2i and CASSANDRA-5576 will add CQL3 support for creating/dropping triggers (CREATE TRIGGER name ON table USING classname). For consistency' sake, CREATE CUSTOM INDEX should be updated to also use 'USING' keyword, e.g. CREATE CUSTOM INDEX ON table(column) USING classname. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10
[ https://issues.apache.org/jira/browse/CASSANDRA-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-5234: Attachment: 5234-1.2-patch.txt I attach 5234-1.2-patch.txt to patch 1.2 branch. It update the last patch with the latest 4421 changes. Table created through CQL3 are not accessble to Pig 0.10 Key: CASSANDRA-5234 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.1 Environment: Red hat linux 5 Reporter: Shamim Ahmed Fix For: 1.2.2 Attachments: 5234-1.2-patch.txt, 5234.tx Hi, i have faced a bug when creating table through CQL3 and trying to load data through pig 0.10 as follows: java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ' at org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112) at org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615). This effects from Simple table to table with compound key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10
[ https://issues.apache.org/jira/browse/CASSANDRA-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683125#comment-13683125 ] Alex Liu commented on CASSANDRA-5234: - The patch resolves the following issues. 1. allow access to cql3 type table through CassandraStorage. 2. create new CqlStorage to easy access cql3 tables. Table created through CQL3 are not accessble to Pig 0.10 Key: CASSANDRA-5234 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.1 Environment: Red hat linux 5 Reporter: Shamim Ahmed Fix For: 1.2.2 Attachments: 5234-1.2-patch.txt, 5234.tx Hi, i have faced a bug when creating table through CQL3 and trying to load data through pig 0.10 as follows: java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ' at org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112) at org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615). This effects from Simple table to table with compound key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10
[ https://issues.apache.org/jira/browse/CASSANDRA-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-5234: Attachment: (was: 5234-1.2-patch.txt) Table created through CQL3 are not accessble to Pig 0.10 Key: CASSANDRA-5234 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.1 Environment: Red hat linux 5 Reporter: Shamim Ahmed Fix For: 1.2.2 Attachments: 5234-1.2-patch.txt, 5234.tx Hi, i have faced a bug when creating table through CQL3 and trying to load data through pig 0.10 as follows: java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ' at org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112) at org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615). This effects from Simple table to table with compound key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10
[ https://issues.apache.org/jira/browse/CASSANDRA-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-5234: Attachment: 5234-1.2-patch.txt Table created through CQL3 are not accessble to Pig 0.10 Key: CASSANDRA-5234 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.1 Environment: Red hat linux 5 Reporter: Shamim Ahmed Fix For: 1.2.2 Attachments: 5234-1.2-patch.txt, 5234.tx Hi, i have faced a bug when creating table through CQL3 and trying to load data through pig 0.10 as follows: java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ' at org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112) at org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615). This effects from Simple table to table with compound key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
