Re: Status of deploy to maven central patch
I would be +1 on this. We need a good way to develop against snapshots. Thanks for your work here Stephen. Stu On Fri, Mar 25, 2011 at 5:35 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Just an FYI. I have the required fixes for Maven ANT Tasks in place: http://jira.codehaus.org/browse/MANTTASKS-217 http://jira.codehaus.org/browse/MANTTASKS-211 http://jira.codehaus.org/browse/MANTTASKS-210 I plan to run a release of Maven ANT Tasks early next week. Once the release is place I should have the patches for 0.8.x and 0.7.x shortly after. Once the 0.7.x patch has landed it would be great if we could spin a 0.7.5 just to trial the patches to verify that they do actually result in a valid release getting pushed all the way to central, and to verify that I have the wiki page for making the release in place -Stephen
Re: plugins/triggers/coprocessors
Honestly, I think we should just mark 1016 a dupe and move forward with 1311: we won't be hurting anyone's feelings, and the implementation from 1016 is: 1. much, much less complete, 2. abandoned. On Fri, Feb 11, 2011 at 9:23 AM, Jeremy Hanna jeremy.hanna1...@gmail.comwrote: Thanks Maxim - I'll just go ahead and BCC you and Hentschel and move the discussion to the dev list. Based on the comments on 1311 - did you have anything else to add to that - could we unify around 1016 or 1311 and work on getting that to a general state of acceptance? Were there any that were able to do some work on either these days? Or are we not at that point? On Feb 11, 2011, at 10:36 AM, Maxim Grinev wrote: Hi all, Jeremy, thanks for starting the discussion! We don't follow the dev list closely so it was a good idea to email it directly. It really seems to be about the same. To unify the discussions, we propose to list the features of each solution and compare them feature by feature. Here is the feature list for triggers: • Triggers are set on a column family. Triggers are executed for each mutation to the column family and parametrized by the mutation. • The mutation, which is the trigger parameter, is the new value. The trigger cannot see the old value. • Triggers are executed asynchronously some time after the write which fired it is acknowledged to the client. • Triggers are executed once during normal execution. We guarantee at least once execution in case of node failures. Cheers, Maxim On Thu, Feb 10, 2011 at 8:45 AM, Jeremy Hanna jeremy.hanna1...@gmail.com wrote: Hey guys, I was just wondering if it would be a good time to unify discussions on plugins/triggers/coprocessors? https://issues.apache.org/jira/browse/CASSANDRA-1016 https://issues.apache.org/jira/browse/CASSANDRA-1311 I was going to email the dev list but since I don't know if all of you follow the dev list and you guys are the ones that expressed the most interest, I thought I would start here. Yeah, they're all tackling basically the same problem. For which we should have a single solution. -ryan
Re: [VOTE] 0.7.1 (what are we at now, 4?)
+1 Passes the distributed tests. On Thu, Feb 10, 2011 at 9:52 AM, Eric Evans eev...@rackspace.com wrote: I propose the following for release as 0.7.1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1069461 0.7.1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: http://goo.gl/5VAPP (CHANGES.txt) [2]: http://goo.gl/C9M5W (NEWS.txt) [3]: http://goo.gl/8dZUr -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.1 (attempt #2)
-1 Kelvin was kind enough to confirm that ALL is broken in this release and trunk. See https://issues.apache.org/jira/browse/CASSANDRA-2094 On Sun, Jan 30, 2011 at 5:24 PM, Stu Hood stuh...@gmail.com wrote: -0 Upgrading from 0.7.0 to these artifacts was fine, but the write ONE read ALL distributed test times out in an unexpected location, with no error messages on the server. The test looks valid, but is also failing in 0.8/trunk. I'll try and bisect it tomorrow from CASSANDRA-1964 (which passed consistently) to the breakage. On Sun, Jan 30, 2011 at 1:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I'm getting Bad Gateway The proxy server received an invalid response from an upstream server. From repository.apache.org. So the Maven central artifacts will probably be staged tomorrow AM (as my wife will kill me if I waste Sunday working on this! and she'd be right too!) ;-) -Stephen On 28 January 2011 20:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I'll drop and restage the artifacts for maven central when I get a chance - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jan 2011 20:30, Eric Evans eev...@rackspace.com wrote: CASSANDRA-2058[1] has landed in 0.7, so let's give this another shot. I propose the following for release as 0.7.1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1064845 0.7.1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: https://issues.apache.org/jira/browse/CASSANDRA-2058 [2]: http://goo.gl/5Tafg (CHANGES.txt) [3]: http://goo.gl/PkreZ (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.1 (attempt #2)
-0 Upgrading from 0.7.0 to these artifacts was fine, but the write ONE read ALL distributed test times out in an unexpected location, with no error messages on the server. The test looks valid, but is also failing in 0.8/trunk. I'll try and bisect it tomorrow from CASSANDRA-1964 (which passed consistently) to the breakage. On Sun, Jan 30, 2011 at 1:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I'm getting Bad Gateway The proxy server received an invalid response from an upstream server. From repository.apache.org. So the Maven central artifacts will probably be staged tomorrow AM (as my wife will kill me if I waste Sunday working on this! and she'd be right too!) ;-) -Stephen On 28 January 2011 20:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I'll drop and restage the artifacts for maven central when I get a chance - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jan 2011 20:30, Eric Evans eev...@rackspace.com wrote: CASSANDRA-2058[1] has landed in 0.7, so let's give this another shot. I propose the following for release as 0.7.1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1064845 0.7.1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: https://issues.apache.org/jira/browse/CASSANDRA-2058 [2]: http://goo.gl/5Tafg (CHANGES.txt) [3]: http://goo.gl/PkreZ (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: Time for 1.0
In that environment, I think the production grade validation is important. A bump in version number does not give you production grade validation: in fact, it is the other way around. I'm -1 on going to 1.0 for the next release. On Thu, Jan 13, 2011 at 9:06 AM, Eric Evans eev...@rackspace.com wrote: On Thu, 2011-01-13 at 16:34 +, Nick Telford wrote: ...or the Ubuntu route and call it Apache Cassandra 11.08 (or whatever month the release occurs in). The number itself is relatively unimportant. And while we're at it, how about a codename in adjective-animal form? Some suggestions: * Funky Monkey * Flatulent Platypus * Leaky Walrus * Ballsy Beaver * Salty Porcupine I could do this all day. :) -- Eric Evans eev...@rackspace.com
Re: [VOTE RESULTS] was: [VOTE] 7.0
Congratulations everyone! On Sun, Jan 9, 2011 at 4:21 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2011-01-06 at 11:17 -0600, Eric Evans wrote: SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0@r1055934 0.7.0 artifacts: http://people.apache.org/~eevans The vote will be open for at least 72 hours. I count 4 binding +1s, 5 others, and no -1s. The vote passes. An ASF press release is scheduled for tomorrow so I'll get the artifacts up tonight, but I'm going to hold off on the announcement until tomorrow. -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.0 rc3
Nick and I discovered https://issues.apache.org/jira/browse/CASSANDRA-1895last night. If someone can reproduce it, it is likely worth delaying this RC for. On Tue, Dec 21, 2010 at 5:22 PM, Eric Evans eev...@rackspace.com wrote: We've had lots of changes[1] since RC2, too many to move to release without wider testing. I propose the following artifacts as 0.7.0 RC3. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1051698 0.7.0-rc3 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: http://goo.gl/VIhDZ (CHANGES.txt) [2]: http://goo.gl/MrxXI (NEWS.txt) [3]: http://goo.gl/HLKlW -- Eric Evans eev...@rackspace.com
Re: CASSANDRA-1472 (bitmap indexes)
Hmm, 500 sstables is definitely a degenerate case: did you disable compaction? By default, Cassandra strives to keep the sstable count below ~32, since accesses to separate sstables require seeks. In this case, the query will seek 500 times to check the secondary index for each sstable: if it finds matches it will need to seek to find them in the primary index, and seek again for the data file. -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Tuesday, November 9, 2010 5:33am To: dev@cassandra.apache.org Subject: Re: CASSANDRA-1472 (bitmap indexes) There are about 500 SSTables (12GB of data including index data, statistics...) The source data file had about 3GB/26 million rows. I only test with EQ expressions for now. Increasing the file limit resolved the problem, but now I'm getting TimedOutException(s) from thrift when querying even with slice size of 1. Is my machine too small (core 2 duo 2.93 2GB RAM Ubuntu 10.04) for such a test? I really have some interesting sets of data to test indexes with and I want to make a comparison between ordinary indexes and bitmap indexes. Thank you, Dragos On Mon, Nov 8, 2010 at 6:42 PM, Stu Hood stu.h...@rackspace.com wrote: Dragos, How many SSTables did you have on disk, and were any of your index expressions GT(E)/LT(E)? I expect that you are bumping into a limitation of the current implementation: it opens up to 128 file-handles per SSTable in the worst case for a GT/LT query (one per index bucket). A future version might remove that requirement, but for now, you should probably bump the file handle limit on your machine to at least 2^16. Thanks, Stu -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Monday, November 8, 2010 10:05am To: dev@cassandra.apache.org Subject: CASSANDRA-1472 (bitmap indexes) Hi, I've got an exception during the following test: test machine: core 2 duo 2.93 2GB RAM Ubuntu 10.04 test scenario: - 1 column family - about 15 columns - 7 indexed columns (bitmap) - 26 million rows (insert operation went fine) - thrift query on 3 of the indexed columns with get_indexed_slices (count: 100) - got the following exception: 10/11/08 17:52:40 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[ReadStage:3,5,main] java.io.IOError: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-814-4-Bitidx.db (Too many open files) at org.apache.cassandra.io.sstable.bitidx.SegmentIterator.open(SegmentIterator.java:78) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.openBin(BitmapIndexReader.java:226) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.iterator(BitmapIndexReader.java:214) at org.apache.cassandra.io.sstable.SSTableReader.scan(SSTableReader.java:523) at org.apache.cassandra.db.secindex.KeysBitmapIndex.iterator(KeysBitmapIndex.java:103) at org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1371) at org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:41) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-814-4-Bitidx.db (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.avro.file.SeekableFileInput.init(SeekableFileInput.java:29) at org.apache.avro.file.DataFileReader.init(DataFileReader.java:38) at org.apache.cassandra.io.sstable.bitidx.SegmentIterator.open(SegmentIterator.java:72) ... 10 more 10/11/08 17:52:40 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[ReadStage:2,5,main] java.io.IOError: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-1018-Index.db (Too many open files) at org.apache.cassandra.io.util.BufferedSegmentedFile.getSegment(BufferedSegmentedFile.java:68) at org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:129) at org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:1) at org.apache.cassandra.io.sstable.SSTableReader.getPosition(SSTableReader.java:455) at org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:572) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:49) at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:72) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:84
Re: CASSANDRA-1472 (bitmap indexes)
Can you tell me a little bit about your key distribution? How many unique values are indexed (the cardinality)? Until the OrBiC projection I mention on 1472 is implemented, the bitmap secondary indexes will perform terribly for high cardinality datasets. Thanks! -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Tuesday, November 9, 2010 10:14am To: dev@cassandra.apache.org Subject: Re: CASSANDRA-1472 (bitmap indexes) Meantime the number of SSTable(s) reduced to just 7. Initially the compaction thread suffered the same problem of too many open files and couldn't do any compaction. But I'm still not able to run my tests: TimedOutException :( On Tue, Nov 9, 2010 at 5:51 PM, Stu Hood stu.h...@rackspace.com wrote: Hmm, 500 sstables is definitely a degenerate case: did you disable compaction? By default, Cassandra strives to keep the sstable count below ~32, since accesses to separate sstables require seeks. In this case, the query will seek 500 times to check the secondary index for each sstable: if it finds matches it will need to seek to find them in the primary index, and seek again for the data file. -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Tuesday, November 9, 2010 5:33am To: dev@cassandra.apache.org Subject: Re: CASSANDRA-1472 (bitmap indexes) There are about 500 SSTables (12GB of data including index data, statistics...) The source data file had about 3GB/26 million rows. I only test with EQ expressions for now. Increasing the file limit resolved the problem, but now I'm getting TimedOutException(s) from thrift when querying even with slice size of 1. Is my machine too small (core 2 duo 2.93 2GB RAM Ubuntu 10.04) for such a test? I really have some interesting sets of data to test indexes with and I want to make a comparison between ordinary indexes and bitmap indexes. Thank you, Dragos On Mon, Nov 8, 2010 at 6:42 PM, Stu Hood stu.h...@rackspace.com wrote: Dragos, How many SSTables did you have on disk, and were any of your index expressions GT(E)/LT(E)? I expect that you are bumping into a limitation of the current implementation: it opens up to 128 file-handles per SSTable in the worst case for a GT/LT query (one per index bucket). A future version might remove that requirement, but for now, you should probably bump the file handle limit on your machine to at least 2^16. Thanks, Stu -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Monday, November 8, 2010 10:05am To: dev@cassandra.apache.org Subject: CASSANDRA-1472 (bitmap indexes) Hi, I've got an exception during the following test: test machine: core 2 duo 2.93 2GB RAM Ubuntu 10.04 test scenario: - 1 column family - about 15 columns - 7 indexed columns (bitmap) - 26 million rows (insert operation went fine) - thrift query on 3 of the indexed columns with get_indexed_slices (count: 100) - got the following exception: 10/11/08 17:52:40 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[ReadStage:3,5,main] java.io.IOError: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-814-4-Bitidx.db (Too many open files) at org.apache.cassandra.io.sstable.bitidx.SegmentIterator.open(SegmentIterator.java:78) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.openBin(BitmapIndexReader.java:226) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.iterator(BitmapIndexReader.java:214) at org.apache.cassandra.io.sstable.SSTableReader.scan(SSTableReader.java:523) at org.apache.cassandra.db.secindex.KeysBitmapIndex.iterator(KeysBitmapIndex.java:103) at org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1371) at org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:41) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-814-4-Bitidx.db (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.avro.file.SeekableFileInput.init(SeekableFileInput.java:29) at org.apache.avro.file.DataFileReader.init(DataFileReader.java:38) at org.apache.cassandra.io.sstable.bitidx.SegmentIterator.open(SegmentIterator.java:72) ... 10 more 10/11/08 17:52:40 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[ReadStage:2,5,main] java.io.IOError
RE: CASSANDRA-1472 (bitmap indexes)
Dragos, How many SSTables did you have on disk, and were any of your index expressions GT(E)/LT(E)? I expect that you are bumping into a limitation of the current implementation: it opens up to 128 file-handles per SSTable in the worst case for a GT/LT query (one per index bucket). A future version might remove that requirement, but for now, you should probably bump the file handle limit on your machine to at least 2^16. Thanks, Stu -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Monday, November 8, 2010 10:05am To: dev@cassandra.apache.org Subject: CASSANDRA-1472 (bitmap indexes) Hi, I've got an exception during the following test: test machine: core 2 duo 2.93 2GB RAM Ubuntu 10.04 test scenario: - 1 column family - about 15 columns - 7 indexed columns (bitmap) - 26 million rows (insert operation went fine) - thrift query on 3 of the indexed columns with get_indexed_slices (count: 100) - got the following exception: 10/11/08 17:52:40 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[ReadStage:3,5,main] java.io.IOError: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-814-4-Bitidx.db (Too many open files) at org.apache.cassandra.io.sstable.bitidx.SegmentIterator.open(SegmentIterator.java:78) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.openBin(BitmapIndexReader.java:226) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.iterator(BitmapIndexReader.java:214) at org.apache.cassandra.io.sstable.SSTableReader.scan(SSTableReader.java:523) at org.apache.cassandra.db.secindex.KeysBitmapIndex.iterator(KeysBitmapIndex.java:103) at org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1371) at org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:41) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-814-4-Bitidx.db (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.avro.file.SeekableFileInput.init(SeekableFileInput.java:29) at org.apache.avro.file.DataFileReader.init(DataFileReader.java:38) at org.apache.cassandra.io.sstable.bitidx.SegmentIterator.open(SegmentIterator.java:72) ... 10 more 10/11/08 17:52:40 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[ReadStage:2,5,main] java.io.IOError: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-1018-Index.db (Too many open files) at org.apache.cassandra.io.util.BufferedSegmentedFile.getSegment(BufferedSegmentedFile.java:68) at org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:129) at org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:1) at org.apache.cassandra.io.sstable.SSTableReader.getPosition(SSTableReader.java:455) at org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:572) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:49) at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:72) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:84) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1190) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1082) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1052) at org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1378) at org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:41) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.FileNotFoundException: /home/dragos/cassandra/data/keyspace/visit-e-1018-Index.db (Too many open files) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.init(RandomAccessFile.java:212) at java.io.RandomAccessFile.init(RandomAccessFile.java:98) at org.apache.cassandra.io.util.BufferedRandomAccessFile.init(BufferedRandomAccessFile.java:142) at org.apache.cassandra.io.util.BufferedSegmentedFile.getSegment(BufferedSegmentedFile.java:62) ... 16 more The same test worked
Re: Calling all library maintainers
Java you serialize a type to a byte[] whereas with the query language you'd serialize to a string term The serializing to a byte[] part is what the RPC libraries exist for. With a string serialization format, you are setting all of your clients up to become string concatenation engines with an ad-hoc format defined by your spec: essentially, duplicating Avro and Thrift. TIMEUUID(timestamp) Note that this same approach is possible in Avro by adding a union type: it is not dependent on String serialization. to serialize that to a string like 10L, than it would be to pack a binary string in network-order I don't think you are giving client library devs enough credit: this only needs to be implemented once, and I'm sure they're capable. -Original Message- From: Eric Evans eev...@rackspace.com Sent: Thursday, November 4, 2010 2:59pm To: client-dev@cassandra.apache.org Subject: Re: Calling all library maintainers On Thu, 2010-11-04 at 21:28 +0200, Ran Tavory wrote: A QL can shield clients from a class of changes, but OTOH will make clients have to compose the query strings, where with type safe libraries this job is somewhat easier. IMO in the near term introducing a query language will make client dev somewhat harder b/c of the (somewhat negligible) work of composing query strings and mostly b/c I don't expect the QL to be stable at v1 so still a moving target, but easier in the the long term mainly due to the hope that the QL will stabilize. I think you could argue that it makes all of this easier. Right now from Java you serialize a type to a byte[] whereas with the query language you'd serialize to a string term. That's a bit more effort out of the gate for primitives like long for example, but consider the venerable TimeUUID that causes so much frustration. I think it would be much easier to take a timestamp and construct a term like TIMEUUID(timestamp) (or whatever), especially since that would work identically across all clients. And it's also worth pointing out that not all languages in use are statically typed, so even in the case of an int, or a long, it'd be easier (or as easy at least), to serialize that to a string like 10L, than it would be to pack a binary string in network-order. As for not being stable, well, yeah it's going to need to bake a bit before being suitable for widespread use, but I raise it here not to encourage everyone to transition now, but so that you can help shape the outcome (if you're interested, of course). One other benefit of query languages is that they make tooling a little easier, one does not have to come up with a specific CLI interpreter or a web interface with a set of input fields, you just have to type your QL into a text box or a terminal like you do with sql. Long term I think I'm in for a QL (although I have to think about the syntax you suggested) but I don't expect it to benefit client devs in the near term even if it was ready today as an alternative to thrift. One small question, does this language tunnel through avro or thrift calls? (Is conn.execute() an avro or thrift call) It's avro for the simple reason that that's still sort of an experimental code path and seemed a less controverial sandbox. When the spec and implementation are complete, and if it gains suitable traction, I'd actually like to explore a customized transport and serialization. -- Eric Evans eev...@rackspace.com
Re: more info CASSANDRA-1472
trunk @ r1029546 -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Monday, November 1, 2010 12:20pm To: dev@cassandra.apache.org Subject: Re: more info CASSANDRA-1472 I can't apply the patches on the latest trunk. Which trunk version (checksum) did you rebased? Thank you! On Mon, Nov 1, 2010 at 6:50 AM, Stu Hood stu.h...@rackspace.com wrote: I can't reproduce this, but I've posted a rebased version on #1472 that you can try out. Thanks for trying it out! -Original Message- From: dragos cernahoschi dragos.cernahos...@gmail.com Sent: Friday, October 29, 2010 10:38am To: dev@cassandra.apache.org Subject: more info CASSANDRA-1472 The stress.py command: 1. python contrib/py_stress/stress.py -C 32 -x keys_bitmap 2. more info from stack trace: 10/10/29 18:15:28 INFO db.Memtable: Writing memtable-standa...@23048841(17806140 bytes, 349140 operations) 10/10/29 18:15:29 INFO service.GCInspector: GC for PS MarkSweep: 789 ms, 7178512 reclaimed leaving 320182640 used; max is 1383202816 10/10/29 18:15:31 ERROR service.AbstractCassandraDaemon: Fatal exception in thread Thread[FlushWriter:1,5,main] java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.avro.io.ResolvingDecoder.readEnum(ResolvingDecoder.java:177) at org.apache.avro.generic.GenericDatumReader.readEnum(GenericDatumReader.java:172) at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:115) at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:118) at org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:142) at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:114) at org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:142) at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:114) at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:105) at org.apache.cassandra.io.SerDeUtils.deserializeWithSchema(SerDeUtils.java:112) at org.apache.cassandra.io.sstable.bitidx.BitmapIndexReader.open(BitmapIndexReader.java:87) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:196) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:178) at org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:160) at org.apache.cassandra.db.Memtable.access$1(Memtable.java:152) at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:172) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 6 more 10/10/29 18:15:38 INFO service.GCInspector: GC for PS MarkSweep: 896 ms, 72939816 reclaimed leaving 341851792 used; max is 1359740928 10/10/29 18:15:38 INFO service.GCInspector: GC for PS Scavenge: 312 ms, 188201560 reclaimed leaving 414791608 used; max is 1359740928 10/10/29 18:15:40 INFO db.ColumnFamilyStore: switching in a fresh Memtable for Standard1 at CommitLogContext(file='/home/dragos/cassandra/commitlog/CommitLog-1288365280350.log', position=111458032) 10/10/29 18:15:40 INFO db.ColumnFamilyStore: Enqueuing flush of memtable-standa...@25762909(17806140 bytes, 349140 operations) 10/10/29 18:15:40 INFO db.Memtable: Writing memtable-standa...@25762909(17806140 bytes, 349140 operations) 10/10/29 18:15:43 INFO service.GCInspector: GC for PS MarkSweep: 1309 ms, 293768 reclaimed leaving 456751520 used; max is 1349451776 10/10/29 18:15:43 INFO service.GCInspector: Pool Name Active Pending 10/10/29 18:15:43 INFO service.GCInspector: ResponseStage 0 0 10/10/29 18:15:43 INFO service.GCInspector: ReadStage 0 0 10/10/29 18:15:43 INFO service.GCInspector: ReadRepair0 0 10/10/29 18:15:43 INFO service.GCInspector: MutationStage 3249 10/10/29 18:15:43 INFO service.GCInspector: GossipStage 0 0 10/10/29 18:15:43 INFO service.GCInspector: AntientropyStage 0 0 10/10/29 18:15:43 INFO service.GCInspector: MigrationStage0 0 10/10/29 18:15:43 INFO service.GCInspector: StreamStage 0 0 10/10/29 18:15:43 INFO service.GCInspector
RE: [VOTE] 0.7.0 beta3
+1 -Original Message- From: Eric Evans eev...@rackspace.com Sent: Thursday, October 28, 2010 10:55am To: dev@cassandra.apache.org Subject: [VOTE] 0.7.0 beta3 The RC1 vote[1] was vetoed due to, (among other things), the desire to see more testing after the somewhat disruptive changes made in CASSANDRA-1367[2]. Thus, I propose the follow artifacts for release as beta3. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1028349 0.7.0-beta3 artifacts: http://people.apache.org/~eevans The vote will be open for the usual 72 hours. [1]: http://article.gmane.org/gmane.comp.db.cassandra.devel/2346 [2]: https://issues.apache.org/jira/browse/CASSANDRA-1367 [3]: http://goo.gl/o0lQ (CHANGES.txt) [4]: http://goo.gl/wFax (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: NoSQL, YesCQL?
Let me preface this by saying: the fact that it looks like SQL doesn't bother me. But: I think this would be a terrible thing to _focus_ on. Something for contrib? Sure. Most reasonable languages these days have a way to define what looks like a DSL: giving people a text DSL which is subject to injection attacks and can't be type checked without support from a client driver anyway is brain dead. There is a reason that 99% of clients that interact with a SQL server do so programmatically via a library: because that is an easier way to interact than via string concatenation. At least that way the library is performing the concatenation for you. Regarding performance: assuming optimized RPC libraries (which we do not yet have in Avro, and which Thrift is getting better at), serializing to a string and back will never be as performant as using a pre-parsed representation of the statement on both sides. Oh but we can add prepared statements! Poppycock. Truth is we've seen quite a bit of proliferation, and very little critical mass. forced to move in lock-step with Cassandra releases, that are never backward compatible Expecting stable libraries or API pre-1.0 is not reasonable: neither the devs nor the users expect stability, and yet we are still able to guarantee compatibility within major versions. The stated problem is that backwards compatibility is hard to provide: if that is the core complaint, then changing to a text based serialization format with a sexy name in order to add backwards compatibility is a severe overreaction to the problem. Instead, I would propose evolving the API in a manner that simplifies it. Thanks, Stu -Original Message- From: Eric Evans eev...@rackspace.com Sent: Thursday, October 28, 2010 4:56pm To: dev@cassandra.apache.org Subject: Re: NoSQL, YesCQL? On Thu, 2010-10-28 at 14:46 -0700, Chip Salzenberg wrote: Short answer: YES Please, but we will still want a side channel for minimum overhead. Ok. Though I'm not sure I agree with the minimum overhead argument. I've only done preliminary tests so far, but this seems on par (if not a little faster) than Thrift is, and no effort to optimize has been made (using a socket transport instead of HTTP for example would make a big difference). Long answer: Query languages only work reliably when you have data binding assistance (insert Bobby Tables xkcd here). However, they do have the wonderful property of evolving aggressively without requiring upgrades of the driver plumbing. This is, of course, emphatically *not* true of anything like the current Thrift and Avro interfaces. So that's why I say Yes. On the other hand, a very simple interface for very simple queries has a lot of value, too; see, for example, http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html So that's why I think we will still want to bypass the full language for minimum latency in some circumstances. I'm also not sure I follow here either. Do you mean simple for the application developer? CQL-using code should be considerably simpler than the equivalent Thrift/Avro. Thanks for the feedback! -- Eric Evans eev...@rackspace.com
RE: [VOTE] 0.7.0 RC1
-1 bin/config-converter failed: see https://issues.apache.org/jira/browse/CASSANDRA-1655 -Original Message- From: Eric Evans eev...@rackspace.com Sent: Friday, October 22, 2010 10:28pm To: dev@cassandra.apache.org Subject: [VOTE] 0.7.0 RC1 We're closing in on a final; it shouldn't be long now. I propose the following for 0.7.0 Release Candidate 1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1026517 0.7.0-rc1 artifacts: http://people.apache.org/~eevans The vote will be open for the usual 72 hours. [1]: http://goo.gl/zLY0 (CHANGES.txt) [2]: http://goo.gl/U5Fo (NEWS.txt) -- Eric Evans eev...@rackspace.com
RE: [VOTE] 0.7.0 RC1
I was able to reproduce it with: bin/cassandra -f bin/cassandra-cli --host localhost --port 9160 Client prints: Exception retrieving information about the cassandra node, check you have connected to the thrift port. Server prints: TProtocolException: Missing version in readMessageBegin, old client? -Original Message- From: Eric Evans eev...@rackspace.com Sent: Saturday, October 23, 2010 11:49am To: dev@cassandra.apache.org Subject: RE: [VOTE] 0.7.0 RC1 On Sat, 2010-10-23 at 11:44 -0500, Stu Hood wrote: Also, client connections fail immediately with a version mismatch: something is not kosher with the Thrift build. Poor cats. Not seeing this, the system tests pass here. -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.0 RC1
And as the last variable, the src artifact builds and does not exhibit the problem, so this is very likely a problem with the classes in the bin artifact. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 1:59pm To: dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 I'm only seeing the problem with the artifacts. -Original Message- From: Jonathan Ellis jbel...@gmail.com Sent: Saturday, October 23, 2010 1:51pm To: dev dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 Are you seeing this just on the artifacts or on trunk? Trunk gives me $ bin/cassandra-cli --host localhost Connected to: Test Cluster on localhost/9160 [defa...@unknown] create keyspace Keyspace1 80379cab-ded6-11df-b235-e700f669bcfc On Sat, Oct 23, 2010 at 11:44 AM, Stu Hood stu.h...@rackspace.com wrote: Also, client connections fail immediately with a version mismatch: something is not kosher with the Thrift build. Poor cats. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 11:28am To: dev@cassandra.apache.org Subject: RE: [VOTE] 0.7.0 RC1 -1 bin/config-converter failed: see https://issues.apache.org/jira/browse/CASSANDRA-1655 -Original Message- From: Eric Evans eev...@rackspace.com Sent: Friday, October 22, 2010 10:28pm To: dev@cassandra.apache.org Subject: [VOTE] 0.7.0 RC1 We're closing in on a final; it shouldn't be long now. I propose the following for 0.7.0 Release Candidate 1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1026517 0.7.0-rc1 artifacts: http://people.apache.org/~eevans The vote will be open for the usual 72 hours. [1]: http://goo.gl/zLY0 (CHANGES.txt) [2]: http://goo.gl/U5Fo (NEWS.txt) -- Eric Evans eev...@rackspace.com -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: [VOTE] 0.7.0 RC1
Ack. This was a framed transport problem... the config converter will leave people in a state where the cli won't connect by default. I guess it's a known issue. Sorry! -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 2:03pm To: dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 And as the last variable, the src artifact builds and does not exhibit the problem, so this is very likely a problem with the classes in the bin artifact. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 1:59pm To: dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 I'm only seeing the problem with the artifacts. -Original Message- From: Jonathan Ellis jbel...@gmail.com Sent: Saturday, October 23, 2010 1:51pm To: dev dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 Are you seeing this just on the artifacts or on trunk? Trunk gives me $ bin/cassandra-cli --host localhost Connected to: Test Cluster on localhost/9160 [defa...@unknown] create keyspace Keyspace1 80379cab-ded6-11df-b235-e700f669bcfc On Sat, Oct 23, 2010 at 11:44 AM, Stu Hood stu.h...@rackspace.com wrote: Also, client connections fail immediately with a version mismatch: something is not kosher with the Thrift build. Poor cats. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 11:28am To: dev@cassandra.apache.org Subject: RE: [VOTE] 0.7.0 RC1 -1 bin/config-converter failed: see https://issues.apache.org/jira/browse/CASSANDRA-1655 -Original Message- From: Eric Evans eev...@rackspace.com Sent: Friday, October 22, 2010 10:28pm To: dev@cassandra.apache.org Subject: [VOTE] 0.7.0 RC1 We're closing in on a final; it shouldn't be long now. I propose the following for 0.7.0 Release Candidate 1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1026517 0.7.0-rc1 artifacts: http://people.apache.org/~eevans The vote will be open for the usual 72 hours. [1]: http://goo.gl/zLY0 (CHANGES.txt) [2]: http://goo.gl/U5Fo (NEWS.txt) -- Eric Evans eev...@rackspace.com -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: [VOTE] 0.7.0 RC1
Sounds reasonable: https://issues.apache.org/jira/browse/CASSANDRA-1659 -Original Message- From: Jonathan Ellis jbel...@gmail.com Sent: Saturday, October 23, 2010 5:08pm To: dev dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 Maybe we should set the new value to unframed always and include a warning if that's not what their 0.6 value was. On Sat, Oct 23, 2010 at 2:08 PM, Stu Hood stu.h...@rackspace.com wrote: Ack. This was a framed transport problem... the config converter will leave people in a state where the cli won't connect by default. I guess it's a known issue. Sorry! -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 2:03pm To: dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 And as the last variable, the src artifact builds and does not exhibit the problem, so this is very likely a problem with the classes in the bin artifact. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 1:59pm To: dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 I'm only seeing the problem with the artifacts. -Original Message- From: Jonathan Ellis jbel...@gmail.com Sent: Saturday, October 23, 2010 1:51pm To: dev dev@cassandra.apache.org Subject: Re: [VOTE] 0.7.0 RC1 Are you seeing this just on the artifacts or on trunk? Trunk gives me $ bin/cassandra-cli --host localhost Connected to: Test Cluster on localhost/9160 [defa...@unknown] create keyspace Keyspace1 80379cab-ded6-11df-b235-e700f669bcfc On Sat, Oct 23, 2010 at 11:44 AM, Stu Hood stu.h...@rackspace.com wrote: Also, client connections fail immediately with a version mismatch: something is not kosher with the Thrift build. Poor cats. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Saturday, October 23, 2010 11:28am To: dev@cassandra.apache.org Subject: RE: [VOTE] 0.7.0 RC1 -1 bin/config-converter failed: see https://issues.apache.org/jira/browse/CASSANDRA-1655 -Original Message- From: Eric Evans eev...@rackspace.com Sent: Friday, October 22, 2010 10:28pm To: dev@cassandra.apache.org Subject: [VOTE] 0.7.0 RC1 We're closing in on a final; it shouldn't be long now. I propose the following for 0.7.0 Release Candidate 1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1026517 0.7.0-rc1 artifacts: http://people.apache.org/~eevans The vote will be open for the usual 72 hours. [1]: http://goo.gl/zLY0 (CHANGES.txt) [2]: http://goo.gl/U5Fo (NEWS.txt) -- Eric Evans eev...@rackspace.com -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
RE: [VOTE] 0.7.0 beta2 (attempt #3)
+1 Tested upgrades from 0.6.5 and 0.7-beta1. -Original Message- From: Eric Evans eev...@rackspace.com Sent: Tuesday, September 28, 2010 12:37pm To: dev@cassandra.apache.org Subject: [VOTE] 0.7.0 beta2 (attempt #3) It feels like 0.7.0-beta1 is becoming too distant a spec in the rear-view, and the delta[1] is becoming quite large. I propose we vote to release a new beta. The previous vote was waved off, so here is a new one. 3rd times the charm? We shall see. SVN: https://svn.apache.org/repos/asf/cassandra/tr...@r1002257 0.7.0-beta2 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours (less if there is another veto). [1]: https://svn.apache.org/repos/asf/cassandra/trunk/CHANGES.txt -- Eric Evans eev...@rackspace.com
Re: launch failure with current git (svn?)
Hey Chip,
Sorry for the trouble! Jon has a patch on
https://issues.apache.org/jira/browse/CASSANDRA-891 that fixes this issue, and
should make it in tomorrow.
Thanks,
Stu
-Original Message-
From: Jonathan Ellis jbel...@gmail.com
Sent: Wednesday, August 25, 2010 9:33pm
To: dev@cassandra.apache.org
Subject: Re: launch failure with current git (svn?)
maybe adding the new default validator is breaking it?
https://issues.apache.org/jira/browse/CASSANDRA-891 in which case
blowing away system keyspace and re-initializing your schema should
fix it
adding new optional fields isn't supposed to break avro serialization tho :(
On Wed, Aug 25, 2010 at 8:39 PM, Chip Salzenberg c...@pobox.com wrote:
I was using svn cassandra from about a week ago, and it worked for me; but
then I updated to today's and got the below error after rebuild.
Help, please: Should I apply some known config file change, or just revert,
or ?
The version failing is
https://svn.apache.org/repos/asf/cassandra/tr...@989392
PS: I'm working on Perl client code, so this really is a dev@ question. :-)
+ exec /usr/bin/java -ea -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -Xms2G -Xmx2G -XX:+HeapDumpOnOutOfMemoryError
-Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=80
-Dcom.sun.management.jmxremote.port=8089
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dlog4j.configuration=log4j-server.properties -Dcassandra-foreground=yes -cp
/home/chip/cassandra/conf:bin/../build/classes:bin/../lib/antlr-3.1.3.jar:bin/../lib/avro-1.4.0-sources~r986959.jar:bin/../lib/avro-1.4.0~r986959.jar:bin/../lib/clhm-production.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-collections-3.2.1.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/guava-r05.jar:bin/../lib/hadoop-core-0.20.1.jar:bin/../lib/high-scale-lib.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jetty-6.1.21.jar:bin/../lib/jetty-util-6.1.21.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/jug-2.0.0.jar:bin/../lib/libthrift-r959516.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.5.8.jar:bin/../lib/slf4j-log4j12-1.5.8.jar:bin/../lib/snakeyaml-1.6.jar
org.apache.cassandra.thrift.CassandraDaemon
INFO 18:35:49,194 JNA not found. Native methods will be disabled.
INFO 18:35:49,299 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 18:35:49,403 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Statistics-e-1-
INFO 18:35:49,417 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Statistics-e-2-
INFO 18:35:49,432 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Schema-e-5-
INFO 18:35:49,437 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Migrations-e-5-
INFO 18:35:49,441 Sampling index for
/var/lib/cassandra/precious_roy/data/system/LocationInfo-e-1-
INFO 18:35:49,442 Sampling index for
/var/lib/cassandra/precious_roy/data/system/LocationInfo-e-2-
INFO 18:35:49,470 Loading schema version
29946d4a-afec-11df-ba37-e700f669bcfc
ERROR 18:35:49,636 Exception encountered during startup.
org.apache.avro.AvroTypeException: Found
{type:record,name:CfDef,namespace:org.apache.cassandra.config.avro,fields:[{name:keyspace,type:string},{name:name,type:string},{name:column_type,type:[string,null]},{name:clock_type,type:[string,null]},{name:comparator_type,type:[string,null]},{name:subcomparator_type,type:[string,null]},{name:reconciler,type:[string,null]},{name:comment,type:[string,null]},{name:row_cache_size,type:[double,null]},{name:preload_row_cache,type:[boolean,null]},{name:key_cache_size,type:[double,null]},{name:read_repair_chance,type:[double,null]},{name:gc_grace_seconds,type:[int,null]},{name:column_metadata,type:[{type:array,items:{type:record,name:ColumnDef,fields:[{name:name,type:bytes},{name:validation_class,type:string},{name:index_type,type:[{type:enum,name:IndexType,symbols:[KEYS]},null]},{name:index_name,type:[string,null]}]}},null]},{name:id,type:[int,null]}]},
expecting
RE: network compatibility from 0.6 to 0.7
So I think we should probably try to preserve compatibility in 0.7. We could probably limit the scope of our network compatibility to steady-state messages, aka, nothing having to do with bootstrap, repair, etc. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Thursday, July 22, 2010 12:35pm To: dev@cassandra.apache.org Subject: RE: network compatibility from 0.6 to 0.7 I feel like the next time we break network compatibility should be the last time, aka, the release when we introduce a backwards compatible RPC layer (Avro?), and implement support for dropping messages that a node can't handle. So I think we should probably try to preserve compatibility in 0.7. -Original Message- From: Jonathan Ellis jbel...@gmail.com Sent: Thursday, July 22, 2010 11:49am To: cassandra-...@incubator.apache.org Subject: network compatibility from 0.6 to 0.7 How useful is this to insist on, given that 0.7 thrift api is fairly incompatible with 0.6's? (timestamp - Clock change being the biggest problem there) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Is SuperColumn necessary?
Hey Ed, I've been working on a similar approach for arbitarily nested/compound column names in #998. See: http://github.com/stuhood/cassandra/blob/998/src/java/org/apache/cassandra/db/ColumnKey.java The goal is to provide native support and potentially (in the very long term), API support for nested/compound names. The difference between our approaches boils down to needing to define a comparator for every level in #998, versus having dynamic types per name in your approach. Thanks, Stu -Original Message- From: Ed Anuff e...@anuff.com Sent: Wednesday, May 5, 2010 1:31pm To: u...@cassandra.apache.org Subject: Re: Is SuperColumn necessary? Follow-up from last weeks discussion, I've been playing around with a simple column comparator for composite column names that I put up on github. I'd be interested to hear what people think of this approach. http://github.com/edanuff/CassandraCompositeType Ed On Wed, Apr 28, 2010 at 12:52 PM, Ed Anuff e...@anuff.com wrote: It might make sense to create a CompositeType subclass of AbstractType for the purpose of constructing and comparing these types of composite column names so that if you could more easily do that sort of thing rather than having to concatenate into one big string. On Wed, Apr 28, 2010 at 10:25 AM, Mike Malone m...@simplegeo.com wrote: The only thing SuperColumns appear to buy you (as someone pointed out to me at the Cassandra meetup - I think it was Eric Florenzano) is that you can use different comparator types for the Super/SubColumns, I guess..? But you should be able to do the same thing by creating your own Column comparator. I guess my point is that SuperColumns are mostly a convenience mechanism, as far as I can tell. Mike
Re: Bootstrap source code
Nodes declare that they will be joining the ring at a particular position, which makes them a member of the 'pending ranges' set. Nodes with pending ranges are supposed to receive writes for those ranges, despite not officially owning them yet. -Original Message- From: Roger Schildmeijer schildmei...@gmail.com Sent: Sunday, May 2, 2010 11:50am To: dev@cassandra.apache.org Subject: Re: Bootstrap source code s/hinted handoff/read repair (Moved to developers mailing list) Without delve to deep into to that part of the code my educated(?) guess is that this will (eventually) be solved/repaired thanks to hinted handoff and anti entropy service. On 2 maj 2010, at 18.29em, Bill Hastings wrote: Hi I have looking at the bootstrap source and seem to understand it for the most part. This is what I do not follow: (1) New node joins and doesn't advertise its token. (2) Requests nodes to send it data. The nodes that need to send it data first flush memtables and then transfer SSTables. Once the streaming is over the new node advertises its token and starts handling reads and writes correct? But what happens to keys that are being written to the old nodes after the memtables have been dumped. Looks like there is a window where keys would be going to the old nodes and not making it to the new nodes. Am I missing something here. -- Cheers Bill
RE: Grep for what?
The actual process is `java`, which should have 'cassandra' as an argument. Make sure to use a variant of `ps` that shows the full command. -Original Message- From: JEFFERY SCHMITZ jefferyschm...@mac.com Sent: Monday, April 5, 2010 12:20pm To: dev@cassandra.apache.org Subject: Grep for what? Warning this is a newbie question - On startup I get [r...@marduk bin]# ./cassandra -f Listening for transport dt_socket at address: INFO - Sampling index for /var/lib/cassandra/data/system/LocationInfo-1-Data.db INFO - Replaying /var/lib/cassandra/commitlog/CommitLog-1270047913578.log INFO - LocationInfo has reached its threshold; switching in a fresh Memtable INFO - Enqueuing flush of Memtable(LocationInfo)@2132679615 INFO - Sorting Memtable(LocationInfo)@2132679615 INFO - Writing Memtable(LocationInfo)@2132679615 INFO - Completed flushing /var/lib/cassandra/data/system/LocationInfo-2-Data.db INFO - Log replay complete INFO - Saved Token found: 75598148438183751486026363636316999593 INFO - Starting up server gossip INFO - Cassandra starting up... Okay so its running I can't figure out what the PID is?? - grepping for cassandra or apache turns up zip - Thanks - Jeffery
