[jira] [Commented] (CASSANDRA-3909) Pig should handle wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255956#comment-13255956 ] Matthew F. Dennis commented on CASSANDRA-3909: -- +1 on inclusion in 1.1.0 (and if not, ASAP after 1.1.0) > Pig should handle wide rows > --- > > Key: CASSANDRA-3909 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3909 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 1.1.1 > > Attachments: 3909.txt > > > Pig should be able to use the wide row support in CFIF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4156) CQL should support CL.TWO
[ https://issues.apache.org/jira/browse/CASSANDRA-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254945#comment-13254945 ] Matthew F. Dennis commented on CASSANDRA-4156: -- tested on EC2 with multiple nodes > CQL should support CL.TWO > - > > Key: CASSANDRA-4156 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4156 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.1 >Reporter: paul cannon >Assignee: Matthew F. Dennis >Priority: Minor > Labels: cql, cql3 > Attachments: cassandra-trunk-4156.txt > > > CL.TWO was overlooked in creating the CQL language spec. It should probably > be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4109) nodetool snapshot should allow specifying list of CFs to snapshot
[ https://issues.apache.org/jira/browse/CASSANDRA-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244635#comment-13244635 ] Matthew F. Dennis commented on CASSANDRA-4109: -- probably, I didn't bother looking that far back ... > nodetool snapshot should allow specifying list of CFs to snapshot > - > > Key: CASSANDRA-4109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4109 > Project: Cassandra > Issue Type: Bug >Reporter: Matthew F. Dennis >Priority: Minor > > nodetool snapshot allows the keyspace to be specified, but not the column > families -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3283) node is sending streams to itself during move operation
[ https://issues.apache.org/jira/browse/CASSANDRA-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199026#comment-13199026 ] Matthew F. Dennis commented on CASSANDRA-3283: -- observed this on 0.8.9 when moving a node. moving a node from 3 node cluster with RF=3 resulted in the node just streaming it's entire dataset to itself > node is sending streams to itself during move operation > --- > > Key: CASSANDRA-3283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3283 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.6 > Environment: linux debian stable (squeeze), cassandra 0.8.6, java 6 > Update 26 >Reporter: Zenek Kraweznik >Assignee: Nick Bailey >Priority: Minor > Fix For: 0.8.10 > > > I'm moving node 10.10.10.231 from 113427455640312821154458202477256070485 to > 0. > ring: > Address DC RackStatus State LoadOwns > Token > > 127605887595351923798765477786913079296 > 10.10.10.232 datacenter1 rack1 Up Normal 148.7 GB50.00% > 42535295865117307932921825928971026432 > 10.10.10.233 datacenter1 rack1 Up Normal 156.77 GB 25.00% > 85070591730234615865843651857942052864 > 10.10.10.231 datacenter1 rack1 Up Moving 188.75 GB 16.67% > 113427455640312821154458202477256070485 > 10.10.10.234 datacenter1 rack1 Up Normal 94.89 GB8.33% > 127605887595351923798765477786913079296 > netstats from node1: > Streaming to: /10.10.10.234 >/var/lib/cassandra/data/testdb2/ChangeLog-g-30-Data.db sections=2 > progress=0/6859992288 - 0% >/var/lib/cassandra/data/testdb2/ChangeLogIndex-g-10-Data.db sections=1 > progress=0/15286 - 0% >/var/lib/cassandra/data/testdb/ChangeLogIndex-g-48-Data.db sections=1 > progress=0/90 - 0% >/var/lib/cassandra/data/testdb/Testcoll-g-107-Data.db sections=2 > progress=0/5276 - 0% >/var/lib/cassandra/data/testdb/Testcoll2-g-74-Data.db sections=2 > progress=0/470 - 0% >/var/lib/cassandra/data/testdb/ChangeLogIndex-g-47-Data.db sections=1 > progress=0/1156 - 0% >/var/lib/cassandra/data/testdb/Testcoll-g-106-Data.db sections=2 > progress=0/329027714 - 0% >/var/lib/cassandra/data/testdb/ChangeLog-g-61-Data.db sections=2 > progress=0/30212596 - 0% >/var/lib/cassandra/data/testdb3/Testcoll2-g-42-Data.db sections=2 > progress=0/774117 - 0% >/var/lib/cassandra/data/testdb3/ChangeLogIndex-g-10-Data.db sections=1 > progress=0/90 - 0% > Streaming to: /10.10.10.231 >/var/lib/cassandra/data/testdb2/Testcoll-g-30-Data.db sections=2 > progress=39059456000/87950308260 - 44% >/var/lib/cassandra/data/testdb2/ChangeLog-g-30-Data.db sections=2 > progress=0/7806077255 - 0% >/var/lib/cassandra/data/testdb2/ChangeLogIndex-g-10-Data.db sections=1 > progress=0/15286 - 0% >/var/lib/cassandra/data/testdb3/Testcoll2-g-42-Data.db sections=2 > progress=0/784033 - 0% >/var/lib/cassandra/data/testdb3/ChangeLogIndex-g-10-Data.db sections=1 > progress=0/90 - 0% >/var/lib/cassandra/data/testdb/ChangeLogIndex-g-48-Data.db sections=1 > progress=0/90 - 0% >/var/lib/cassandra/data/testdb/Testcoll-g-107-Data.db sections=2 > progress=0/10499 - 0% >/var/lib/cassandra/data/testdb/Testcoll2-g-74-Data.db sections=2 > progress=0/1042 - 0% >/var/lib/cassandra/data/testdb/ChangeLogIndex-g-47-Data.db sections=1 > progress=0/1156 - 0% >/var/lib/cassandra/data/testdb/Testcoll-g-106-Data.db sections=2 > progress=0/329965993 - 0% >/var/lib/cassandra/data/testdb/ChangeLog-g-61-Data.db sections=2 > progress=0/24633913 - 0% > Streaming from: /10.10.10.231 >testdb: /var/lib/cassandra/data/testdb/ChangeLogIndex-g-47-Data.db > sections=1 progress=0/1156 - 0% >testdb: /var/lib/cassandra/data/testdb/ChangeLogIndex-g-48-Data.db > sections=1 progress=0/90 - 0% >testdb: /var/lib/cassandra/data/testdb/ChangeLog-g-61-Data.db sections=2 > progress=0/24633913 - 0% >testdb3: /var/lib/cassandra/data/testdb3/Testcoll2-g-42-Data.db sections=2 > progress=0/784033 - 0% >testdb: /var/lib/cassandra/data/testdb/Testcoll2-g-74-Data.db sections=2 > progress=0/1042 - 0% >testdb3: /var/lib/cassandra/data/testdb3/ChangeLogIndex-g-10-Data.db > sections=1 progress=0/90 - 0% >testdb2: /var/lib/cassandra/data/testdb2/ChangeLog-g-30-Data.db sections=2 > progress=0/7806077255 - 0% >testdb2: /var/lib/cassandra/data/testdb2/ChangeLogIndex-g-10-Data.db > sections=1 progress=0/15286 - 0% >testdb: /var/lib/cassandra/data/testdb/Testcoll-g-106-Data.db sections=2 > progress=0/329965993 - 0% >testdb2: /var/lib/cassandra/data/t
[jira] [Commented] (CASSANDRA-3705) Don't default the datacenter name in replication_strategies when the datacenter does not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181068#comment-13181068
]
Matthew F. Dennis commented on CASSANDRA-3705:
--
I'm in favor of always requiring a that the RF for at least one DC be set when
creating a keyspace.
We should not allow a RF to be set for a DC that doesn't exist, or at the very
least not default it to a DC that doesn't actually exist.
> Don't default the datacenter name in replication_strategies when the
> datacenter does not exist
> --
>
> Key: CASSANDRA-3705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3705
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.0.5
>Reporter: Joaquin Casares
>
> When using the AMI, which is currently set to use the EC2 snitch and the
> NetworkTopologyStrategy is set to default by the cli, all keyspaces default
> to datacenter1 being the datacenter name.
> So when running:
> {noformat}
> create keyspace test;
> {noformat}
> we get this created:
> {noformat}
> Keyspace: test:
> Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
> Durable Writes: true
> Options: [datacenter1:1]
> {noformat}
> This should error out immediately rather than letting the user go on to
> discover the error later:
> {noformat}
> [default@test] set User['jsmith']['first'] = 'John';
> null
> UnavailableException()
> at
> org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
> at
> org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
> at org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
> at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:902)
> at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:216)
> at
> org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
> at org.apache.cassandra.cli.CliMain.main(CliMain.java:346)
> {noformat}
> Related link:
> http://www.datastax.com/support-forums/topic/new-datastax-ami-ami-fd23ec94-is-not-functionnal
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3643) Cassandra C CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171435#comment-13171435 ] Matthew F. Dennis commented on CASSANDRA-3643: -- I agree that C (and C++) access to Cassandra is pretty lacking at the moment. The problems you mention with thrift+c is part of the reason for that: any C driver for Cassandra would have to run over thrift (though the burden would be all the driver devs, not everyone who wants to use C and Cassandra together). Even for CQL though, a C driver will still be communicating via thrift and having to deal with all the ... eccentricities that come along with it. > Cassandra C CQL driver > -- > > Key: CASSANDRA-3643 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3643 > Project: Cassandra > Issue Type: Wish > Components: Drivers >Affects Versions: 1.0.6 > Environment: all >Reporter: Vlad Paiu >Priority: Blocker > Labels: C, cql, driver > > It's really a shame that such a great project like Cassandra doesn't support > a way for it to be used from within a C application. > Thrift has never worked for C or it is very poorly documented. Either way, > integrating Cassandra with an application written in C is just not possible > in an elegant manner at the current moment in time. > With the development of CQL, it would really be great if one could run CQL > commands from within a C library, very much like libmysqlclient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2786) After a minor compaction, deleted key-slices are visible again
[
https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154786#comment-13154786
]
Matthew F. Dennis commented on CASSANDRA-2786:
--
I should mention that I did change one line in the test. I changed
{noformat}column.timestamp = getTimestamp();{noformat} to
{noformat}column.setTimestamp(getTimestamp());{noformat} because otherwise
thrift complained that the timestamp wasn't set.
> After a minor compaction, deleted key-slices are visible again
> --
>
> Key: CASSANDRA-2786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2786
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.8.0, 0.8.7
> Environment: Reproduced on single Cassandra node (CentOS 5.5)
> Reproduced on single Cassandra node (Windows Server 2008)
>Reporter: rene kochen
>Assignee: Sylvain Lebresne
> Fix For: 0.8.1, 0.8.2
>
> Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch,
> 2786_part2.patch, CassandraIssue.zip, CassandraIssueJava.zip
>
>
> After a minor compaction, deleted key-slices are visible again.
> Steps to reproduce:
> 1) Insert a row named "test".
> 2) Insert 50 rows. During this step, row "test" is included in a major
> compaction:
>file-1, file-2, file-3 and file-4 compacted to file-5 (includes "test").
> 3) Delete row named "test".
> 4) Insert 50 rows. During this step, row "test" is included in a minor
> compaction:
>file-6, file-7, file-8 and file-9 compacted to file-10 (should include
> tombstoned "test").
> After step 4, row "test" is live again.
> Test environment:
> Single node with empty database.
> Standard configured super-column-family (I see this behavior with several
> gc_grace settings (big and small values):
> create column family Customers with column_type = 'Super' and comparator =
> 'BytesType;
> In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the
> row is still deleted.
> I've included a .NET program to reproduce the problem. I will add a Java
> version later on.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2786) After a minor compaction, deleted key-slices are visible again
[ https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154784#comment-13154784 ] Matthew F. Dennis commented on CASSANDRA-2786: -- Per previous phone conversation, I tested this against 0.8.7 twice. Both times the attached java test ran to completion against a single node and output "Done". When was this last reproduced? > After a minor compaction, deleted key-slices are visible again > -- > > Key: CASSANDRA-2786 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2786 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0, 0.8.7 > Environment: Reproduced on single Cassandra node (CentOS 5.5) > Reproduced on single Cassandra node (Windows Server 2008) >Reporter: rene kochen >Assignee: Sylvain Lebresne > Fix For: 0.8.1, 0.8.2 > > Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch, > 2786_part2.patch, CassandraIssue.zip, CassandraIssueJava.zip > > > After a minor compaction, deleted key-slices are visible again. > Steps to reproduce: > 1) Insert a row named "test". > 2) Insert 50 rows. During this step, row "test" is included in a major > compaction: >file-1, file-2, file-3 and file-4 compacted to file-5 (includes "test"). > 3) Delete row named "test". > 4) Insert 50 rows. During this step, row "test" is included in a minor > compaction: >file-6, file-7, file-8 and file-9 compacted to file-10 (should include > tombstoned "test"). > After step 4, row "test" is live again. > Test environment: > Single node with empty database. > Standard configured super-column-family (I see this behavior with several > gc_grace settings (big and small values): > create column family Customers with column_type = 'Super' and comparator = > 'BytesType; > In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the > row is still deleted. > I've included a .NET program to reproduce the problem. I will add a Java > version later on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3453) cassandra.yaml needs a snapshot_directory setting
[ https://issues.apache.org/jira/browse/CASSANDRA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144423#comment-13144423 ] Matthew F. Dennis commented on CASSANDRA-3453: -- we provide a setting for controlling the data directories, which is currently a parent of all the snapshots directories, so you already have the referenced problems (i.e. checking a setting to find out where your snapshots are and potentially forgetting to update it on a new machine). Furthermore, if I have N out of M keyspaces I want to snapshot and backup (or bulk load to another cluster or ...) after the snapshot I have to remember each keyspace so I can then construct a path to each snapshot (e.g. /path/from/data_dir/setting/$ks_name/snapshots/$snapshot_name) in order to do what I wanted to do with the snapshots instead of knowing everything I care about is in one place (e.g. /path/from/snapshot_dir/setting/$snapshot_name). > cassandra.yaml needs a snapshot_directory setting > - > > Key: CASSANDRA-3453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3453 > Project: Cassandra > Issue Type: Improvement >Reporter: Matthew F. Dennis > > cassandra.yaml really needs a config option for a snapshot directory. by > default it should be a peer folder with saved_caches, commitlog and data. > assuming the value of that setting is /some/path/snapshot_dir then snapshots > would go into: /some/path/snapshot_dir/snapshot_name/keyspace_name/ > this makes automation, particularly around backups, much easier and gives > more control to ops -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3453) cassandra.yaml needs a directory_setting
[ https://issues.apache.org/jira/browse/CASSANDRA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144384#comment-13144384 ] Matthew F. Dennis commented on CASSANDRA-3453: -- 1) It is easier to backup/copy all your snapshots for all keyspaces if they are in one place instead of having to iterate over all the keyspace directories looking for the snapshot directories. 2) it is safer when deleting snapshots (less chance of scripts/admins accidentally deleting the keyspace instead of all the snapshots. (e.g. rm -rf /some/path/$ksname/snapshots/* where $ksname ends up a blank space because of a script bug) besides, checking a setting isn't very complex code wise ;) > cassandra.yaml needs a directory_setting > > > Key: CASSANDRA-3453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3453 > Project: Cassandra > Issue Type: Improvement >Reporter: Matthew F. Dennis > > cassandra.yaml really needs a config option for a snapshot directory. by > default it should be a peer folder with saved_caches, commitlog and data. > assuming the value of that setting is /some/path/snapshot_dir then snapshots > would go into: /some/path/snapshot_dir/snapshot_name/keyspace_name/ > this makes automation, particularly around backups, much easier and gives > more control to ops -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
