[jira] [Updated] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Harvey updated CASSANDRA-2309:
Affects Version/s: 0.7.4
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010023#comment-13010023
]
Jason Harvey commented on CASSANDRA-2309:
-
I have several tables with unordered keys, and they also can't be exported via
sstable2json. The sstable2json attempt is throwing the following. I do have the
patch for #2318. Running 0.7.4:
{code}
Exception in thread main java.lang.NullPointerException
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:67)
at
org.apache.cassandra.io.sstable.SSTableReader.createColumnFamily(SSTableReader.java:583)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:110)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:67)
at
org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:179)
at
org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:144)
at
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:136)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:293)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:324)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:337)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:395)
{code}
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010024#comment-13010024
]
Jason Harvey commented on CASSANDRA-2309:
-
Also, another very scary thing. The sstables with the unordered keys were
written within the last couple days. What might cause sstables with unordered
keys to be written in 0.7.4?
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of FrontPage_JP by MakiWatanabe
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The FrontPage_JP page has been changed by MakiWatanabe. The comment on this change is: Add link to Cassandra UG Japan. http://wiki.apache.org/cassandra/FrontPage_JP?action=diffrev1=78rev2=79 -- * Cassandra開発者メーリングリスト： d...@cassandra.apache.org [[mailto:dev-subscr...@cassandra.apache.org|(購読する)]] [[http://www.mail-archive.com/dev@cassandra.apache.org/|(アーカイブ)]] [[http://www.mail-archive.com/cassandra-dev@incubator.apache.org/|(インキュベーター アーカイブ)]] * Cassandraコミット通知用メーリングリスト: commits@cassandra.apache.org [[mailto:commits-subscr...@cassandra.apache.org|(購読する)]] + == 日本におけるコミュニティ == + * [[https://sites.google.com/site/cassandrajapan/home|日本Cassandraユーザ会]] + == 関連ドキュメント == * [[http://incubator.apache.org/thrift|Thrift]]: クライアントがCassandraへのアクセスに使っているライブラリー
[Cassandra Wiki] Update of ThirdPartySupport by Apeksha
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThirdPartySupport page has been changed by Apeksha.
http://wiki.apache.org/cassandra/ThirdPartySupport?action=diffrev1=6rev2=7
--
{{http://www.datastax.com/sites/all/themes/datastax20110201/logo.png}}
[[http://datastax.com|Datastax]] provides professional Cassandra support and
services.
+ {{http://www.impetus.com/sites/impetus.com/impetus/gifs/logo_impetus.png}}
[[http://www.impetus.com/ |Impetus]] provides expertise in Cassandra, Hbase,
+
+ MongoDB, and Other databases like Riak, Redis, Membase, Tokyocabinet, etc
[[http://bigdata.impetus.com/# | More info about BigData @Impetus]]
+
{{http://www.onzra.com/images/Small-Logo.gif}} [[http://www.ONZRA.com|ONZRA]]
provides enterprise grade Cassandra architecture and development services.
{{http://www.acunu.com/images/logo-small.png}} [[http://www.acunu.com|Acunu]]
provides software products for Cassandra applications, as well as Cassandra
support and professional services.
+
+
+
(Other providers are welcome to add themselves to this publicly-editable
page.)
[Cassandra Wiki] Update of ArchitectureAntiEntropy by JingguoYao
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArchitectureAntiEntropy page has been changed by JingguoYao. The comment on this change is: Disable wiki links. http://wiki.apache.org/cassandra/ArchitectureAntiEntropy?action=diffrev1=3rev2=4 -- == Anti-entropy Overview == - AntiEntropyService generates MerkleTrees for column families during major compactions. These trees are then exchanged with remote nodes via a TreeRequest/TreeResponse conversation, and when ranges in the trees disagree, the 'org.apache.cassandra.streaming' package is used to repair those ranges. + !AntiEntropyService generates !MerkleTrees for column families during major compactions. These trees are then exchanged with remote nodes via a !TreeRequest/!TreeResponse conversation, and when ranges in the trees disagree, the 'org.apache.cassandra.streaming' package is used to repair those ranges. Tree comparison and repair triggering occur in the single threaded AE_SERVICE_STAGE. The steps taken to enact a repair are as follows: 1. A major compaction is triggered either via nodeprobe, or automatically: - * Nodeprobe sends TreeRequest messages to all neighbors of the target node: when a node receives a TreeRequest, it will perform a readonly compaction to immediately validate the column family. + * Nodeprobe sends !TreeRequest messages to all neighbors of the target node: when a node receives a !TreeRequest, it will perform a readonly compaction to immediately validate the column family. - * Automatic compactions will also validate a column family and broadcast TreeResponses, but since TreeRequest messages are not sent to neighboring nodes, repairs will only occur if two nodes happen to perform automatic compactions within TREE_STORE_TIMEOUT of one another. + * Automatic compactions will also validate a column family and broadcast !TreeResponses, but since !TreeRequest messages are not sent to neighboring nodes, repairs will only occur if two nodes happen to perform automatic compactions within TREE_STORE_TIMEOUT of one another. 2. The compaction process validates the column family by: - * Calling getValidator() (which can return a NoopValidator if validation should not be performed), + * Calling getValidator() (which can return a !NoopValidator if validation should not be performed), * Calling IValidator.prepare(), which samples the column family to determine key distribution, * Calling IValidator.add() in order for every row in the column family, * Calling IValidator.complete() to indicate that all rows have been added. - * If getValidator decided that the column family should be validated, calling complete() indicates that a valid MerkleTree has been created for the column family. + * If getValidator decided that the column family should be validated, calling complete() indicates that a valid !MerkleTree has been created for the column family. - * The valid tree is broadcast to neighboring nodes via TreeResponse, and stored locally. + * The valid tree is broadcast to neighboring nodes via !TreeResponse, and stored locally. - 3. When a node receives a TreeResponse, it passes the tree to rendezvous(), which checks for trees to rendezvous with / compare to: + 3. When a node receives a !TreeResponse, it passes the tree to rendezvous(), which checks for trees to rendezvous with / compare to: * If the tree is local, it is cached, and compared to any trees that were received from neighbors. * If the tree is remote, it is immediately compared to a local tree if one is cached. Otherwise, the remote tree is cached in case a local tree is generated within TREE_STORE_TIMEOUT. * A Differencer object is enqueued for each comparison. @@ -28, +28 @@ === TODO === Repairs currently require 2 major compactions: one to validate a column family, and then another to send the disagreeing ranges. - One possible fix to this problem would be to use something like a [[http://comonad.com/reader/2008/linear-bloom-filters/|Linear Bloom Filter]] to store a summary of every SSTable on disk, where each sub-bloom is partitioned using 'midpoint()' like the current MerkleTree. Then, to validate a column family, you could OR together the bloom filters for each SSTable, and send it to neighbors without performing a compaction. + One possible fix to this problem would be to use something like a [[http://comonad.com/reader/2008/linear-bloom-filters/|Linear Bloom Filter]] to store a summary of every SSTable on disk, where each sub-bloom is partitioned using 'midpoint()' like the current !MerkleTree. Then, to validate a column family, you could OR together the bloom filters for each SSTable, and send it to neighbors without performing a compaction.
[Cassandra Wiki] Update of ArchitectureAntiEntropy by JingguoYao
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArchitectureAntiEntropy page has been changed by JingguoYao. The comment on this change is: Disable wiki links. http://wiki.apache.org/cassandra/ArchitectureAntiEntropy?action=diffrev1=4rev2=5 -- == Anti-entropy Overview == - !AntiEntropyService generates !MerkleTrees for column families during major compactions. These trees are then exchanged with remote nodes via a !TreeRequest/!TreeResponse conversation, and when ranges in the trees disagree, the 'org.apache.cassandra.streaming' package is used to repair those ranges. + !AntiEntropyService generates !MerkleTrees for column families during major compactions. These trees are then exchanged with remote nodes via a !TreeRequest/TreeResponse conversation, and when ranges in the trees disagree, the 'org.apache.cassandra.streaming' package is used to repair those ranges. Tree comparison and repair triggering occur in the single threaded AE_SERVICE_STAGE.
[Cassandra Wiki] Update of ArchitectureInternals by JingguoYao
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArchitectureInternals page has been changed by JingguoYao. The comment on this change is: Disable wiki links. http://wiki.apache.org/cassandra/ArchitectureInternals?action=diffrev1=19rev2=20 -- * When a Memtable is full, it gets sorted and written out as an SSTable asynchronously by !ColumnFamilyStore.switchMemtable * When enough SSTables exist, they are merged by !CompactionManager.doCompaction * Making this concurrency-safe without blocking writes or reads while we remove the old SSTables from the list and add the new one is tricky, because naive approaches require waiting for all readers of the old sstables to finish before deleting them (since we can't know if they have actually started opening the file yet; if they have not and we delete the file first, they will error out). The approach we have settled on is to not actually delete old SSTables synchronously; instead we register a phantom reference with the garbage collector, so when no references to the SSTable exist it will be deleted. (We also write a compaction marker to the file system so if the server is restarted before that happens, we clean out the old SSTables at startup time.) - * A major compaction of merging _all_ sstables may be manually initiated by the user; this results in submitMajor calling doCompaction with all the sstables in the ColumnFamily, rather than just sstables of similar size. + * A major compaction of merging _all_ sstables may be manually initiated by the user; this results in submitMajor calling doCompaction with all the sstables in the !ColumnFamily, rather than just sstables of similar size. * See [[ArchitectureSSTable]] and ArchitectureCommitLog for more details = Read path =
[jira] [Commented] (CASSANDRA-2191) Multithread across compaction buckets
[ https://issues.apache.org/jira/browse/CASSANDRA-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010077#comment-13010077 ] Aaron Morton commented on CASSANDRA-2191: - I have a bunch of questions mostly because I'm trying to understand the reasons for doing things. # If max is 0 SSTableTracker.markCompacting() will return an empty list rather than null. # CompactionManager.submitMinorIfNeeded() sorts the SSTables in the bucket to compact the older ones first. When the list is passed to SSTableTracker.markCompacting() the order is lost. # In CompactionManager.submitIndexBuild() and submmitSSTableBuild() should the calls to executor be in an inner try block to ensure the lock is always released. # If the size of the thread pool for CompactionManager.CompactionExecutor() is not configurable is there a risk of using too many threads and saturating the IO with compaction? Could some people want less than 1 thread per core? # For my understanding: What about the CompactionExecutor using the JMXEnabledThreadPoolExecutor so it's stats come back in TP Stats ? # There is a comment in CompactionManager.doCompaction() about relying on a single thread in compaction to when determining if it's a major compaction. # The order in which the buckets are processed appears to be undefined. Would it make sense to order them by number of files or avg size so there is a more predictable outcome with multiple threads possibly working through a similar set of files? # For my understanding: Have you considered adding a flag to so that a minor compaction will stop processing buckets if additional threads have started? I think this may make the compaction less aggressive as it would more quickly fall back to a single thread until more were needed again. # The order of the list returned from CompactionExecutor.getCompactions() is undefined. Could they be returned in the order they were added to the executor to make to the data returned from CompactionExecutor.getColumnFamilyInProgress() more reliable? Multithread across compaction buckets - Key: CASSANDRA-2191 URL: https://issues.apache.org/jira/browse/CASSANDRA-2191 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Priority: Critical Labels: compaction Fix For: 0.8 Attachments: 0001-Add-a-compacting-set-to-sstabletracker.txt, 0002-Use-the-compacting-set-of-sstables-to-schedule-multith.txt, 0003-Expose-multiple-compactions-via-JMX-and-deprecate-sing.txt This ticket overlaps with CASSANDRA-1876 to a degree, but the approaches and reasoning are different enough to open a separate issue. The problem with compactions currently is that they compact the set of sstables that existed the moment the compaction started. This means that for longer running compactions (even when running as fast as possible on the hardware), a very large number of new sstables might be created in the meantime. We have observed this proliferation of sstables killing performance during major/high-bucketed compactions. One approach would be to pause compactions in upper buckets (containing larger files) when compactions in lower buckets become possible. While this would likely solve the problem with read performance, it does not actually help us perform compaction any faster, which is a reasonable requirement for other situations. Instead, we need to be able to perform any compactions that are currently required in parallel, independent of what bucket they might be in. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010100#comment-13010100
]
Jonathan Ellis commented on CASSANDRA-2309:
---
bq. The sstable2json attempt is throwing the following
That looks a lot like sstable2json couldn't find the Cassandra schema
bq. What might cause sstables with unordered keys to be written in 0.7.4?
Possibly some kind of ByteBuffer race, although you'd think more people would
hit that. Are the keys correct-but-unordered or unordered-and-garbage?
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2367) Cleanup conversions between bytes and strings
Cleanup conversions between bytes and strings - Key: CASSANDRA-2367 URL: https://issues.apache.org/jira/browse/CASSANDRA-2367 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.5 Attachments: 0001-Cleanup-bytes-string-conversions.patch There is a bit of inconsistency in our conversions between ByteBuffers and Strings. For instance, ByteBufferUtil.string() uses as a default the java default charset, while ByteBufferUtil.bytes(String) assumes UTF8. Moreover, a number of places in the code don't use those functions and uses getBytes() directly. There again, we often encode with the default charset but decode in UTF8 or the contrary. Using the default charset is probably a bad idea anyway, since this depends on the actual system the node is running on and could lead to a stupid bug when running in heterogeneous systems. This ticket proposes to always assume UTF8 all over the place (and tries to use the ByteBufferUtil as much as possible to help with that). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2367) Cleanup conversions between bytes and strings
[ https://issues.apache.org/jira/browse/CASSANDRA-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2367: Attachment: 0001-Cleanup-bytes-string-conversions.patch Attaching patch against 0.7. Cleanup conversions between bytes and strings - Key: CASSANDRA-2367 URL: https://issues.apache.org/jira/browse/CASSANDRA-2367 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.5 Attachments: 0001-Cleanup-bytes-string-conversions.patch Original Estimate: 2h Remaining Estimate: 2h There is a bit of inconsistency in our conversions between ByteBuffers and Strings. For instance, ByteBufferUtil.string() uses as a default the java default charset, while ByteBufferUtil.bytes(String) assumes UTF8. Moreover, a number of places in the code don't use those functions and uses getBytes() directly. There again, we often encode with the default charset but decode in UTF8 or the contrary. Using the default charset is probably a bad idea anyway, since this depends on the actual system the node is running on and could lead to a stupid bug when running in heterogeneous systems. This ticket proposes to always assume UTF8 all over the place (and tries to use the ByteBufferUtil as much as possible to help with that). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2341) Cli support for counters
[ https://issues.apache.org/jira/browse/CASSANDRA-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010150#comment-13010150 ] Jonathan Ellis commented on CASSANDRA-2341: --- patch does not apply for me on trunk Cli support for counters Key: CASSANDRA-2341 URL: https://issues.apache.org/jira/browse/CASSANDRA-2341 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Add-counter-support-to-cli.patch Original Estimate: 6h Remaining Estimate: 6h The cli should have support for counters operation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2341) Cli support for counters
[ https://issues.apache.org/jira/browse/CASSANDRA-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2341: Attachment: 0001-Add-counter-support-to-cli-v2.patch This is because of CASSANDRA-2354. Attaching v2 rebased and taking the consistencyLevel into account for counter operation too. Cli support for counters Key: CASSANDRA-2341 URL: https://issues.apache.org/jira/browse/CASSANDRA-2341 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Add-counter-support-to-cli-v2.patch, 0001-Add-counter-support-to-cli.patch Original Estimate: 6h Remaining Estimate: 6h The cli should have support for counters operation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2341) Cli support for counters
[ https://issues.apache.org/jira/browse/CASSANDRA-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010177#comment-13010177 ] Pavel Yaskevich commented on CASSANDRA-2341: +1 on v2 Cli support for counters Key: CASSANDRA-2341 URL: https://issues.apache.org/jira/browse/CASSANDRA-2341 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Add-counter-support-to-cli-v2.patch, 0001-Add-counter-support-to-cli.patch Original Estimate: 6h Remaining Estimate: 6h The cli should have support for counters operation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084616 - in /cassandra/trunk: src/java/org/apache/cassandra/cli/ test/unit/org/apache/cassandra/cli/
Author: brandonwilliams
Date: Wed Mar 23 15:41:21 2011
New Revision: 1084616
URL: http://svn.apache.org/viewvc?rev=1084616view=rev
Log:
Add counter support to the cli.
Patch by Sylvain Lebresne, reviewed by Pavel Yaskevich for
CASSANDRA-2341.
Modified:
cassandra/trunk/src/java/org/apache/cassandra/cli/Cli.g
cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java
cassandra/trunk/src/java/org/apache/cassandra/cli/CliCompleter.java
cassandra/trunk/src/java/org/apache/cassandra/cli/CliUserHelp.java
cassandra/trunk/test/unit/org/apache/cassandra/cli/CliTest.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/cli/Cli.g
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cli/Cli.g?rev=1084616r1=1084615r2=1084616view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cli/Cli.g (original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cli/Cli.g Wed Mar 23 15:41:21
2011
@@ -49,6 +49,8 @@ tokens {
NODE_THRIFT_SET;
NODE_THRIFT_COUNT;
NODE_THRIFT_DEL;
+NODE_THRIFT_INCR;
+NODE_THRIFT_DECR;
NODE_ADD_COLUMN_FAMILY;
NODE_ADD_KEYSPACE;
NODE_DEL_KEYSPACE;
@@ -152,6 +154,7 @@ statement
| getStatement
| helpStatement
| setStatement
+| incrStatement
| showStatement
| listStatement
| truncateStatement
@@ -204,6 +207,10 @@ helpStatement
- ^(NODE_HELP NODE_THRIFT_GET)
| HELP SET
- ^(NODE_HELP NODE_THRIFT_SET)
+| HELP INCR
+- ^(NODE_HELP NODE_THRIFT_INCR)
+| HELP DECR
+- ^(NODE_HELP NODE_THRIFT_DECR)
| HELP DEL
- ^(NODE_HELP NODE_THRIFT_DEL)
| HELP COUNT
@@ -230,7 +237,7 @@ exitStatement
getStatement
: GET columnFamilyExpr ('AS' typeIdentifier)?
- ^(NODE_THRIFT_GET columnFamilyExpr ( ^(CONVERT_TO_TYPE
typeIdentifier) )? )
-| GET columnFamily 'WHERE' getCondition ('AND' getCondition)* ('LIMIT'
limit=IntegerLiteral)*
+| GET columnFamily 'WHERE' getCondition ('AND' getCondition)* ('LIMIT'
limit=IntegerPositiveLiteral)*
- ^(NODE_THRIFT_GET_WITH_CONDITIONS columnFamily ^(CONDITIONS
getCondition+) ^(NODE_LIMIT $limit)*)
;
@@ -244,14 +251,21 @@ operator
;
typeIdentifier
-: Identifier | StringLiteral | IntegerLiteral
+: Identifier | StringLiteral | IntegerPositiveLiteral
;
setStatement
-: SET columnFamilyExpr '=' objectValue=value (WITH TTL '=' ttlValue=value)?
+: SET columnFamilyExpr '=' objectValue=value (WITH TTL '='
ttlValue=IntegerPositiveLiteral)?
- ^(NODE_THRIFT_SET columnFamilyExpr $objectValue ( $ttlValue )?)
;
+incrStatement
+: INCR columnFamilyExpr (BY byValue=incrementValue)?
+- ^(NODE_THRIFT_INCR columnFamilyExpr ( $byValue )?)
+| DECR columnFamilyExpr (BY byValue=incrementValue)?
+- ^(NODE_THRIFT_DECR columnFamilyExpr ( $byValue )?)
+;
+
countStatement
: COUNT columnFamilyExpr
- ^(NODE_THRIFT_COUNT columnFamilyExpr)
@@ -269,7 +283,7 @@ showStatement
;
listStatement
-: LIST columnFamily keyRangeExpr? ('LIMIT' limit=IntegerLiteral)?
+: LIST columnFamily keyRangeExpr? ('LIMIT' limit=IntegerPositiveLiteral)?
- ^(NODE_LIST columnFamily keyRangeExpr? ^(NODE_LIMIT $limit)?)
;
@@ -408,7 +422,7 @@ attrValueString
;
attrValueInt
- : IntegerLiteral
+ : IntegerPositiveLiteral
;
attrValueDouble
@@ -428,7 +442,7 @@ replica_placement_strategy
;
replication_factor
- : IntegerLiteral
+ : IntegerPositiveLiteral
;
keyspaceNewName
@@ -457,11 +471,11 @@ columnFamily
;
rowKey
-: (Identifier | StringLiteral | IntegerLiteral | functionCall)
+: (Identifier | StringLiteral | IntegerPositiveLiteral | functionCall)
;
value
-: (Identifier | IntegerLiteral | StringLiteral | functionCall)
+: (Identifier | IntegerPositiveLiteral | StringLiteral | functionCall)
;
functionCall
@@ -470,7 +484,7 @@ functionCall
;
functionArgument
-: Identifier | StringLiteral | IntegerLiteral
+: Identifier | StringLiteral | IntegerPositiveLiteral
;
startKey
@@ -482,7 +496,7 @@ endKey
;
columnOrSuperColumn
- : (Identifier | IntegerLiteral | StringLiteral | functionCall)
+ : (Identifier | IntegerPositiveLiteral | StringLiteral | functionCall)
;
host
@@ -501,9 +515,14 @@ ip_address
port
-: IntegerLiteral
+: IntegerPositiveLiteral
;
+incrementValue
+: IntegerNegativeLiteral
+| IntegerPositiveLiteral
+;
+
//
// Lexer Section
//
@@ -526,6 +545,8 @@ EXIT:'EXIT';
FILE:'FILE';
QUIT:'QUIT';
SET: 'SET';
+INCR:'INCR';
+DECR:'DECR';
SHOW:'SHOW';
KEYSPACE:'KEYSPACE';
KEYSPACES: 'KEYSPACES';
@@ -535,6 +556,7 @@ DROP:
[jira] [Resolved] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2368. --- Resolution: Not A Problem autobootstrap=false means don't transfer the data to the new node, that should belong to it. so you should set it to true when adding nodes to a cluster with data in it. see http://wiki.apache.org/cassandra/Operations Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-47) SSTable compression
[ https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010192#comment-13010192 ] Jonathan Ellis commented on CASSANDRA-47: - We can do this (and CASSANDRA-1717) without a full-on rewrite of the sstable layer. As I said 18 months ago (!): bq. A very straightforward way to compress would be on a per-[column]index-block basis. for large rows this should work well The trickier part is compressing small rows as well, efficiently. We can do this by adding rows into blocks (using the same tunable parameter for block size) and changing the index entry to a 3-tuple: key, compressed block offset from start of file, offset of row from start of block once uncompressed. Either kind of block should end with a checksum to handle CASSANDRA-1717. So we would have two types of compression, rows-in-blocks and blocks-in-rows. We decide at write time which to use based on our sstable row size statistics: if average row size is less than 10% of the index block size, and max row size is strictly less than that size, then we use rows-in-blocks; otherwise, we use blocks-in-rows. So we bias towards blocks-in-rows to avoid uncompressing data we don't need so much. SSTable compression --- Key: CASSANDRA-47 URL: https://issues.apache.org/jira/browse/CASSANDRA-47 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 We should be able to do SSTable compression which would trade CPU for I/O (almost always a good trade). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010196#comment-13010196 ] Markus Wiesenbacher commented on CASSANDRA-2368: But I can´t find the rows on the existing node anymore, where have they gone to? Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-47) SSTable compression
[ https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010197#comment-13010197 ] Brandon Williams commented on CASSANDRA-47: --- I think is idea hits the sweet spot where we currently stand. Compression is a *huge* win for us, and not having to rewrite the entire format simplifies the complexity greatly. SSTable compression --- Key: CASSANDRA-47 URL: https://issues.apache.org/jira/browse/CASSANDRA-47 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 We should be able to do SSTable compression which would trade CPU for I/O (almost always a good trade). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-47) SSTable compression
[ https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010197#comment-13010197 ] Brandon Williams edited comment on CASSANDRA-47 at 3/23/11 4:16 PM: I think this idea hits the sweet spot where we currently stand. Compression is a *huge* win for us, and not having to rewrite the entire format simplifies the complexity greatly. was (Author: brandon.williams): I think is idea hits the sweet spot where we currently stand. Compression is a *huge* win for us, and not having to rewrite the entire format simplifies the complexity greatly. SSTable compression --- Key: CASSANDRA-47 URL: https://issues.apache.org/jira/browse/CASSANDRA-47 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 We should be able to do SSTable compression which would trade CPU for I/O (almost always a good trade). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010200#comment-13010200 ] Jonathan Ellis commented on CASSANDRA-2368: --- The old node will route queries to the new node too. Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2341) Cli support for counters
[ https://issues.apache.org/jira/browse/CASSANDRA-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010203#comment-13010203 ] Hudson commented on CASSANDRA-2341: --- Integrated in Cassandra #798 (See [https://hudson.apache.org/hudson/job/Cassandra/798/]) Add counter support to the cli. Patch by Sylvain Lebresne, reviewed by Pavel Yaskevich for CASSANDRA-2341. Cli support for counters Key: CASSANDRA-2341 URL: https://issues.apache.org/jira/browse/CASSANDRA-2341 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Add-counter-support-to-cli-v2.patch, 0001-Add-counter-support-to-cli.patch Original Estimate: 6h Remaining Estimate: 6h The cli should have support for counters operation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was:
0001-Add-optional-IndexClause-to-KeyRange-and-serialize-wit.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0002-Drop-the-IndexClause.count-parameter.txt,
0003-Execute-RangeSliceCommands-using-scan-when-an-IndexCla.txt,
0004-Remove-get_indexed_slices-method.txt,
0005-Update-system-tests-to-use-get_range_slices.txt,
0006-Remove-start_key-from-IndexClause-for-the-start_key-in.txt,
0007-Respect-end_key-for-filtered-queries.txt,
0008-allow-applying-row-filtering-to-sequential-scan.txt,
0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was: 0002-Drop-the-IndexClause.count-parameter.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was:
0003-Execute-RangeSliceCommands-using-scan-when-an-IndexCla.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was: 0005-Update-system-tests-to-use-get_range_slices.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was: 0004-Remove-get_indexed_slices-method.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was:
0006-Remove-start_key-from-IndexClause-for-the-start_key-in.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was:
0008-allow-applying-row-filtering-to-sequential-scan.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was: 0007-Respect-end_key-for-filtered-queries.txt)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments: 0009-rename-Index-Filter.txt, AbstractScanIterator.java
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: (was: AbstractScanIterator.java)
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments:
0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt,
0002-allow-get_range_slices-to-apply-filter-to-a-sequential.txt
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1600:
--
Attachment: 0002-allow-get_range_slices-to-apply-filter-to-a-sequential.txt
0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 0.7 beta 1
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.7.5
Attachments:
0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt,
0002-allow-get_range_slices-to-apply-filter-to-a-sequential.txt
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010205#comment-13010205 ] Markus Wiesenbacher commented on CASSANDRA-2368: I am not sure if you understand me correctly. My new node didn't have any data and some old rows don't appear anymore, not on the old not on the new node. Von meinem iPhone gesendet Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2369) support replication decisions per-key
support replication decisions per-key - Key: CASSANDRA-2369 URL: https://issues.apache.org/jira/browse/CASSANDRA-2369 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8 Currently the replicationstrategy gets a token and a keyspace with which to decide how to place replicas. for per-row replication this is insufficient because tokenization is lossy (CASSANDRA-1034). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2367) Cleanup conversions between bytes and strings
[ https://issues.apache.org/jira/browse/CASSANDRA-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010226#comment-13010226 ] Jonathan Ellis commented on CASSANDRA-2367: --- I see two places this fixes bugs: - HintedHandOffManger: post-delivery hint deletion is now done w/ UTF8 encoding, which matches old and new encoding of ip-address-as-string. - SystemTable now encodes cluster name as UTF8; before it encoded as system encoding, decoded as UTF8. Is that accurate? Cleanup conversions between bytes and strings - Key: CASSANDRA-2367 URL: https://issues.apache.org/jira/browse/CASSANDRA-2367 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.5 Attachments: 0001-Cleanup-bytes-string-conversions.patch Original Estimate: 2h Remaining Estimate: 2h There is a bit of inconsistency in our conversions between ByteBuffers and Strings. For instance, ByteBufferUtil.string() uses as a default the java default charset, while ByteBufferUtil.bytes(String) assumes UTF8. Moreover, a number of places in the code don't use those functions and uses getBytes() directly. There again, we often encode with the default charset but decode in UTF8 or the contrary. Using the default charset is probably a bad idea anyway, since this depends on the actual system the node is running on and could lead to a stupid bug when running in heterogeneous systems. This ticket proposes to always assume UTF8 all over the place (and tries to use the ByteBufferUtil as much as possible to help with that). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2367) Cleanup conversions between bytes and strings
[ https://issues.apache.org/jira/browse/CASSANDRA-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010239#comment-13010239 ] Sylvain Lebresne commented on CASSANDRA-2367: - There is also: * the avro schema (DEFINITION_SCHEMA_COLUMN_NAME) for mutation. I was encoded in UTF8 (in Migration.java), but decoded using system encoding (in DefsTable.loadFromStorage(), since decoded by ByteBufferUtil.string() with default charset). * In HintedHandOffManager, the combined table and cfName is encoded as UTF8 but decoded with system encoding (once again through the use of BBUtil.string() with no specific charset. Cleanup conversions between bytes and strings - Key: CASSANDRA-2367 URL: https://issues.apache.org/jira/browse/CASSANDRA-2367 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.5 Attachments: 0001-Cleanup-bytes-string-conversions.patch Original Estimate: 2h Remaining Estimate: 2h There is a bit of inconsistency in our conversions between ByteBuffers and Strings. For instance, ByteBufferUtil.string() uses as a default the java default charset, while ByteBufferUtil.bytes(String) assumes UTF8. Moreover, a number of places in the code don't use those functions and uses getBytes() directly. There again, we often encode with the default charset but decode in UTF8 or the contrary. Using the default charset is probably a bad idea anyway, since this depends on the actual system the node is running on and could lead to a stupid bug when running in heterogeneous systems. This ticket proposes to always assume UTF8 all over the place (and tries to use the ByteBufferUtil as much as possible to help with that). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084652 - /cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py
Author: jbellis
Date: Wed Mar 23 17:48:46 2011
New Revision: 1084652
URL: http://svn.apache.org/viewvc?rev=1084652view=rev
Log:
give index more time to build to avoid heisenfailures
Modified:
cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py
Modified: cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py?rev=1084652r1=1084651r2=1084652view=diff
==
--- cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py
(original)
+++ cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py Wed Mar
23 17:48:46 2011
@@ -1406,7 +1406,7 @@ class TestMutations(ThriftTester):
assert server_cf.column_metadata[0].index_name ==
modified_cd.index_name
# sleep a bit to give time for the index to build.
-time.sleep(0.1)
+time.sleep(0.5)
# simple query on one index expression
cp = ColumnParent('ToBeIndexed')
[jira] [Commented] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010253#comment-13010253 ] Markus Wiesenbacher commented on CASSANDRA-2368: Just to get sure that everybody understands my problem: 1. Node1 has some column families where each contains one row. 2. I set up a fresh Node2 (no data), leave AutoBootStrap on false. 3. I can search on both nodes, but some rows are not found on Node1 and not on Node2. So my question is: Where are they? Maybe I don´t understand some principles of Cassandra .. My next step is to try to decommission Node2, maybe my data comes back. Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Wiesenbacher reopened CASSANDRA-2368: Please have a look again, I really don´t get it ... Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010269#comment-13010269 ] Jonathan Ellis commented on CASSANDRA-2368: --- Did you read the Operations page? It explains what you are seeing. Please follow up to the user list with further questions, not here. Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084660 [2/2] - in /cassandra/branches/cassandra-0.7: ./ contrib/bmt_example/ contrib/client_only/src/ contrib/stress/src/org/apache/cassandra/contrib/stress/ contrib/stress/src/org/apach
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TimeSortTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TimeSortTest.java?rev=1084660r1=1084659r2=1084660view=diff
==
---
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TimeSortTest.java
(original)
+++
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TimeSortTest.java
Wed Mar 23 18:13:42 2011
@@ -68,7 +68,7 @@ public class TimeSortTest extends Cleanu
for (int i = 900; i 1000; ++i)
{
-RowMutation rm = new RowMutation(Keyspace1,
ByteBuffer.wrap(Integer.toString(i).getBytes()));
+RowMutation rm = new RowMutation(Keyspace1,
ByteBufferUtil.bytes(Integer.toString(i)));
for (int j = 0; j 8; ++j)
{
rm.add(new QueryPath(StandardLong1, null, getBytes(j * 2)),
ByteBufferUtil.bytes(a), j * 2);
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/LazilyCompactedRowTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/LazilyCompactedRowTest.java?rev=1084660r1=1084659r2=1084660view=diff
==
---
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/LazilyCompactedRowTest.java
(original)
+++
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/LazilyCompactedRowTest.java
Wed Mar 23 18:13:42 2011
@@ -150,7 +150,7 @@ public class LazilyCompactedRowTest exte
Table table = Table.open(Keyspace1);
ColumnFamilyStore cfs = table.getColumnFamilyStore(Standard1);
-ByteBuffer key =ByteBuffer.wrap( k.getBytes() );
+ByteBuffer key = ByteBufferUtil.bytes(k);
RowMutation rm = new RowMutation(Keyspace1, key);
rm.add(new QueryPath(Standard1, null, ByteBufferUtil.bytes(c)),
ByteBufferUtil.EMPTY_BYTE_BUFFER, 0);
rm.add(new QueryPath(Standard1, null, ByteBufferUtil.bytes(d)),
ByteBufferUtil.EMPTY_BYTE_BUFFER, 0);
@@ -212,9 +212,9 @@ public class LazilyCompactedRowTest exte
final int ROWS_PER_SSTABLE = 10;
for (int j = 0; j (DatabaseDescriptor.getIndexInterval() * 3) /
ROWS_PER_SSTABLE; j++) {
for (int i = 0; i ROWS_PER_SSTABLE; i++) {
-ByteBuffer key = ByteBuffer.wrap(String.valueOf(i %
2).getBytes());
+ByteBuffer key = ByteBufferUtil.bytes(String.valueOf(i % 2));
RowMutation rm = new RowMutation(Keyspace1, key);
-rm.add(new QueryPath(Standard1, null,
ByteBuffer.wrap(String.valueOf(i / 2).getBytes())),
ByteBufferUtil.EMPTY_BYTE_BUFFER, j * ROWS_PER_SSTABLE + i);
+rm.add(new QueryPath(Standard1, null,
ByteBufferUtil.bytes(String.valueOf(i / 2))), ByteBufferUtil.EMPTY_BYTE_BUFFER,
j * ROWS_PER_SSTABLE + i);
rm.apply();
}
cfs.forceBlockingFlush();
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java?rev=1084660r1=1084659r2=1084660view=diff
==
---
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
(original)
+++
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
Wed Mar 23 18:13:42 2011
@@ -28,6 +28,7 @@ import org.apache.cassandra.CleanupHelpe
import org.apache.cassandra.db.DecoratedKey;
import org.apache.cassandra.db.columniterator.SSTableNamesIterator;
import org.apache.cassandra.utils.FBUtilities;
+import org.apache.cassandra.utils.ByteBufferUtil;
import org.junit.BeforeClass;
import org.junit.Test;
@@ -99,7 +100,7 @@ public class LegacySSTableTest extends C
SSTableReader reader = SSTableReader.open(getDescriptor(version));
for (String keystring : TEST_DATA)
{
-ByteBuffer key = ByteBuffer.wrap(keystring.getBytes());
+ByteBuffer key = ByteBufferUtil.bytes(keystring);
// confirm that the bloom filter does not reject any keys/names
DecoratedKey dk = reader.partitioner.decorateKey(key);
SSTableNamesIterator iter = new SSTableNamesIterator(reader,
dk, FBUtilities.singleton(key));
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java?rev=1084660r1=1084659r2=1084660view=diff
[jira] [Commented] (CASSANDRA-2367) Cleanup conversions between bytes and strings
[ https://issues.apache.org/jira/browse/CASSANDRA-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010270#comment-13010270 ] Jonathan Ellis commented on CASSANDRA-2367: --- committed to 0.7 w/ some build fixes for contrib/ (so you will want to base port to trunk on r1084660) Cleanup conversions between bytes and strings - Key: CASSANDRA-2367 URL: https://issues.apache.org/jira/browse/CASSANDRA-2367 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.5 Attachments: 0001-Cleanup-bytes-string-conversions.patch Original Estimate: 2h Remaining Estimate: 2h There is a bit of inconsistency in our conversions between ByteBuffers and Strings. For instance, ByteBufferUtil.string() uses as a default the java default charset, while ByteBufferUtil.bytes(String) assumes UTF8. Moreover, a number of places in the code don't use those functions and uses getBytes() directly. There again, we often encode with the default charset but decode in UTF8 or the contrary. Using the default charset is probably a bad idea anyway, since this depends on the actual system the node is running on and could lead to a stupid bug when running in heterogeneous systems. This ticket proposes to always assume UTF8 all over the place (and tries to use the ByteBufferUtil as much as possible to help with that). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2368) Cassandra loses rows when a new node is added to the cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2368. - Resolution: Invalid Cassandra loses rows when a new node is added to the cluster Key: CASSANDRA-2368 URL: https://issues.apache.org/jira/browse/CASSANDRA-2368 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Markus Wiesenbacher Hi, I have a node with some column families each containing 1 row with several columns. Now I setup a new node (AutoBootStrap = false) and get the scheme/data. If I check both nodes for the rows, some rows are missing. Best regards Markus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2367) Cleanup conversions between bytes and strings
[ https://issues.apache.org/jira/browse/CASSANDRA-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010280#comment-13010280 ] Hudson commented on CASSANDRA-2367: --- Integrated in Cassandra-0.7 #401 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/401/]) fix encoding bugs in HintedHandoffManager, SystemTable when default charset is not UTF8 patch by slebresne; reviewed by jbellis for CASSANDRA-2367 Cleanup conversions between bytes and strings - Key: CASSANDRA-2367 URL: https://issues.apache.org/jira/browse/CASSANDRA-2367 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.7.5 Attachments: 0001-Cleanup-bytes-string-conversions.patch Original Estimate: 2h Remaining Estimate: 2h There is a bit of inconsistency in our conversions between ByteBuffers and Strings. For instance, ByteBufferUtil.string() uses as a default the java default charset, while ByteBufferUtil.bytes(String) assumes UTF8. Moreover, a number of places in the code don't use those functions and uses getBytes() directly. There again, we often encode with the default charset but decode in UTF8 or the contrary. Using the default charset is probably a bad idea anyway, since this depends on the actual system the node is running on and could lead to a stupid bug when running in heterogeneous systems. This ticket proposes to always assume UTF8 all over the place (and tries to use the ByteBufferUtil as much as possible to help with that). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084665 - in /cassandra/trunk/test/unit/org/apache/cassandra/io/sstable: SSTableUtils.java SSTableWriterCommutativeTest.java SSTableWriterTest.java
Author: jbellis
Date: Wed Mar 23 18:36:44 2011
New Revision: 1084665
URL: http://svn.apache.org/viewvc?rev=1084665view=rev
Log:
r/m uses of SSTableUtils.writeRaw
patch by Stu Hood; reviewed by jbellis for CASSANDRA-2366
Modified:
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableUtils.java
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableWriterCommutativeTest.java
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableWriterTest.java
Modified:
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableUtils.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableUtils.java?rev=1084665r1=1084664r2=1084665view=diff
==
--- cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableUtils.java
(original)
+++ cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableUtils.java
Wed Mar 23 18:36:44 2011
@@ -154,6 +154,7 @@ public class SSTableUtils
/**
* @Deprecated: Writes the binary content of a row, which should be
encapsulated.
*/
+@Deprecated
public SSTableReader writeRaw(MapByteBuffer, ByteBuffer entries)
throws IOException
{
File datafile = (dest == null) ? tempSSTableFile(ksname, cfname,
generation) : new File(dest.filenameFor(Component.DATA));
Modified:
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableWriterCommutativeTest.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableWriterCommutativeTest.java?rev=1084665r1=1084664r2=1084665view=diff
==
---
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableWriterCommutativeTest.java
(original)
+++
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/SSTableWriterCommutativeTest.java
Wed Mar 23 18:36:44 2011
@@ -58,16 +58,16 @@ public class SSTableWriterCommutativeTes
String keyspace = Keyspace1;
String cfname = Counter1;
-MapByteBuffer, ByteBuffer entries = new HashMapByteBuffer,
ByteBuffer();
-MapByteBuffer, ByteBuffer cleanedEntries = new HashMapByteBuffer,
ByteBuffer();
+MapString, ColumnFamily entries = new HashMapString,
ColumnFamily();
+MapString, ColumnFamily cleanedEntries = new HashMapString,
ColumnFamily();
-DataOutputBuffer buffer;
-
-ColumnFamily cf = ColumnFamily.create(keyspace, cfname);
-ColumnFamily cfCleaned = ColumnFamily.create(keyspace, cfname);
+ColumnFamily cf;
+ColumnFamily cfCleaned;
CounterContext.ContextState state;
// key: k
+cf = ColumnFamily.create(keyspace, cfname);
+cfCleaned = ColumnFamily.create(keyspace, cfname);
state = CounterContext.ContextState.allocate(4, 1);
state.writeElement(NodeId.fromInt(2), 9L, 3L, true);
state.writeElement(NodeId.fromInt(4), 4L, 2L);
@@ -84,24 +84,12 @@ public class SSTableWriterCommutativeTes
cf.addColumn(new CounterColumn( ByteBufferUtil.bytes(y),
state.context, 0L));
cfCleaned.addColumn(new CounterColumn( ByteBufferUtil.bytes(y),
cc.clearAllDelta(state.context), 0L));
-buffer = new DataOutputBuffer();
-ColumnFamily.serializer().serializeWithIndexes(cf, buffer);
-entries.put(
-ByteBufferUtil.bytes(k),
-ByteBuffer.wrap(Arrays.copyOf(buffer.getData(),
buffer.getLength()))
-);
-
-buffer = new DataOutputBuffer();
-ColumnFamily.serializer().serializeWithIndexes(cfCleaned, buffer);
-cleanedEntries.put(
-ByteBufferUtil.bytes(k),
-ByteBuffer.wrap(Arrays.copyOf(buffer.getData(),
buffer.getLength()))
-);
-
-cf.clear();
-cfCleaned.clear();
+entries.put(k, cf);
+cleanedEntries.put(k, cfCleaned);
// key: l
+cf = ColumnFamily.create(keyspace, cfname);
+cfCleaned = ColumnFamily.create(keyspace, cfname);
state = CounterContext.ContextState.allocate(4, 1);
state.writeElement(NodeId.fromInt(2), 9L, 3L, true);
state.writeElement(NodeId.fromInt(4), 4L, 2L);
@@ -117,25 +105,11 @@ public class SSTableWriterCommutativeTes
cf.addColumn(new CounterColumn( ByteBufferUtil.bytes(y),
state.context, 0L));
cfCleaned.addColumn(new CounterColumn( ByteBufferUtil.bytes(y),
cc.clearAllDelta(state.context), 0L));
-buffer = new DataOutputBuffer();
-ColumnFamily.serializer().serializeWithIndexes(cf, buffer);
-entries.put(
-ByteBufferUtil.bytes(l),
-ByteBuffer.wrap(Arrays.copyOf(buffer.getData(),
buffer.getLength()))
-);
-
-buffer = new DataOutputBuffer();
-ColumnFamily.serializer().serializeWithIndexes(cfCleaned,
[jira] [Commented] (CASSANDRA-2280) Request specific column families using StreamIn
[ https://issues.apache.org/jira/browse/CASSANDRA-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010287#comment-13010287 ] Jonathan Ellis commented on CASSANDRA-2280: --- I'd prefer to avoid special-casing empty list and just pass all CF names when that is what we want. A constructor or factory method that does not take a columnFamilies parameter could default to that, too. (This is easy w/ CFS.all, but that would require using CFS objects instead of Strings. Which may be better anyway but it is hard to tell w/o trying it.) Nit: we usually use cfs to abbreviate ColumnFamilyStore, suggest expanding to columnFamilies. Request specific column families using StreamIn --- Key: CASSANDRA-2280 URL: https://issues.apache.org/jira/browse/CASSANDRA-2280 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Fix For: 0.8 Attachments: 0001-Allow-specific-column-families-to-be-requested-for-str.txt, 0002-Only-flush-matching-CFS.txt StreamIn.requestRanges only specifies a keyspace, meaning that requesting a range will request it for all column families: if you have a large number of CFs, this can cause quite a headache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084674 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/cli/Cli.g test/unit/org/apache/cassandra/cli/CliTest.java
Author: jbellis
Date: Wed Mar 23 18:56:21 2011
New Revision: 1084674
URL: http://svn.apache.org/viewvc?rev=1084674view=rev
Log:
allow negative numbers in the cli
patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-2358
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/cli/CliTest.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1084674r1=1084673r2=1084674view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Wed Mar 23 18:56:21 2011
@@ -17,6 +17,7 @@
* fix potential infinite loop in ByteBufferUtil.inputStream (CASSANDRA-2365)
* fix encoding bugs in HintedHandoffManager, SystemTable when default
charset is not UTF8 (CASSANDRA-2367)
+ * allow negative numbers in the cli (CASSANDRA-2358)
0.7.4
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g?rev=1084674r1=1084673r2=1084674view=diff
==
--- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
(original)
+++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/Cli.g
Wed Mar 23 18:56:21 2011
@@ -569,6 +569,7 @@ Alnum
// syntactic Elements
IntegerLiteral
: Digit+
+ | '-' Digit+
;
DoubleLiteral
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/cli/CliTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/cli/CliTest.java?rev=1084674r1=1084673r2=1084674view=diff
==
---
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/cli/CliTest.java
(original)
+++
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/cli/CliTest.java
Wed Mar 23 18:56:21 2011
@@ -39,7 +39,11 @@ public class CliTest extends CleanupHelp
use TestKeySpace;,
create column family CF1 with comparator=UTF8Type and
column_metadata=[{ column_name:world, validation_class:IntegerType,
index_type:0, index_name:IdxName }, { column_name:world2,
validation_class:LongType, index_type:KEYS, index_name:LongIdxName}];,
set CF1[hello][world] = 123848374878933948398384;,
+set CF1[hello][-31337] = 'some string value';,
+get CF1[hello][-31337];,
get CF1[hello][world];,
+set CF1[hello][-31337] = -23876;,
+set CF1[hello][-31337] = long(-23876);,
set CF1[hello][world2] = 15;,
get CF1 where world2 = long(15);,
get cF1 where world2 = long(15);,
@@ -79,6 +83,10 @@ public class CliTest extends CleanupHelp
del SCF1['hello'][1][];,
get SCF1['hello'][1][];,
set SCF1['hello'][1][] = Long(1234);,
+set SCF1['hello'][-1][-12] = Long(5678);,
+get SCF1['hello'][-1][-12];,
+set SCF1['hello'][-1][-12] = -340897;,
+set SCF1['hello'][-1][-12] = integer(-340897);,
del SCF1['hello'][];,
get SCF1['hello'][1][];,
truncate CF1;,
[jira] [Updated] (CASSANDRA-1125) Filter out ColumnFamily rows that aren't part of the query
[ https://issues.apache.org/jira/browse/CASSANDRA-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1125: -- Fix Version/s: 0.8 Issue Type: New Feature (was: Improvement) CASSANDRA-1600 has a patch now. So what we need here is to allow specifying a KeyRange to the job. This will give us index queries for free; for start/end limits we'd need to and limit each split to its intersection with the KeyRange start/end in CFIF. This would be easy but we ripped out the AbstractBounds intersection code (in part because we were never quite sure if it was entirely debugged). Time to take another stab at that, or are there other ideas? Filter out ColumnFamily rows that aren't part of the query -- Key: CASSANDRA-1125 URL: https://issues.apache.org/jira/browse/CASSANDRA-1125 Project: Cassandra Issue Type: New Feature Components: Hadoop Reporter: Jeremy Hanna Priority: Minor Fix For: 0.8 Currently, when running a MapReduce job against data in a Cassandra data store, it reads through all the data for a particular ColumnFamily. This could be optimized to only read through those rows that have to do with the query. It's a small change but wanted to put it in Jira so that it didn't fall through the cracks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2336) Extract SSTable.Builder/IndexWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2336: -- Reviewer: slebresne Priority: Minor (was: Major) Extract SSTable.Builder/IndexWriter --- Key: CASSANDRA-2336 URL: https://issues.apache.org/jira/browse/CASSANDRA-2336 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Stu Hood Priority: Minor Fix For: 0.8 Attachments: 0001-Extract-IndexWriter.txt, 0002-Extract-Builder.txt, 0003-Move-statistics-writing-into-IndexWriter.txt The Builder and IndexWriter classes in SSTableWriter are static, and independently useful. Additionally, we need the ability to subclass them for CASSANDRA-674 and CASSANDRA-2319. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2247) Cleanup unused imports and generics
[ https://issues.apache.org/jira/browse/CASSANDRA-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010299#comment-13010299 ] Jonathan Ellis commented on CASSANDRA-2247: --- Sorry, just worked my review heap down to this. Can you rebase to current trunk? Cleanup unused imports and generics --- Key: CASSANDRA-2247 URL: https://issues.apache.org/jira/browse/CASSANDRA-2247 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.8 Attachments: CASSANDRA-2247-part1.diff, CASSANDRA-2247-part2.diff In current cassandra trunk are many classes which import packages which are never used. The same is true for Loggers which are often instanced and then not used. Beside this I see many warnings related to generic usage. Would be nice to clean this up a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2366) Remove more uses of SSTableUtils.writeRaw
[ https://issues.apache.org/jira/browse/CASSANDRA-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010301#comment-13010301 ] Hudson commented on CASSANDRA-2366: --- Integrated in Cassandra #799 (See [https://hudson.apache.org/hudson/job/Cassandra/799/]) r/m uses of SSTableUtils.writeRaw patch by Stu Hood; reviewed by jbellis for CASSANDRA-2366 Remove more uses of SSTableUtils.writeRaw - Key: CASSANDRA-2366 URL: https://issues.apache.org/jira/browse/CASSANDRA-2366 Project: Cassandra Issue Type: Test Reporter: Stu Hood Assignee: Stu Hood Fix For: 0.8 Attachments: 0001-CASSANDRA-2366-Remove-some-uses-of-SSTableUtils.writeR.txt writeRaw uses the binary memtable write path, and is consequently 1. complex, 2. fragile. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2358) CLI doesn't handle inserting negative integers
[
https://issues.apache.org/jira/browse/CASSANDRA-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010315#comment-13010315
]
Hudson commented on CASSANDRA-2358:
---
Integrated in Cassandra-0.7 #402 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/402/])
allow negative numbers in the cli
patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-2358
CLI doesn't handle inserting negative integers
--
Key: CASSANDRA-2358
URL: https://issues.apache.org/jira/browse/CASSANDRA-2358
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0
Reporter: Tyler Hobbs
Assignee: Pavel Yaskevich
Priority: Trivial
Fix For: 0.7.5
Attachments: CASSANDRA-2358.patch
Original Estimate: 0.5h
Remaining Estimate: 0.5h
The CLI raises a syntax error when trying to insert negative integers:
{noformat}
[default@Keyspace1] set StandardInteger['key'][-12] = 'val';
Syntax error at position 28: mismatched character '1' expecting '-'
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2370) unstable repo has disappeared from http://www.apache.org/dist/cassandra/debian/dists/
unstable repo has disappeared from http://www.apache.org/dist/cassandra/debian/dists/ - Key: CASSANDRA-2370 URL: https://issues.apache.org/jira/browse/CASSANDRA-2370 Project: Cassandra Issue Type: Bug Components: Packaging Environment: The entire internet Reporter: Brandon Williams Assignee: Eric Evans -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010317#comment-13010317
]
Jason Harvey commented on CASSANDRA-2309:
-
bq. That looks a lot like sstable2json couldn't find the Cassandra schema
I grabbed some debug output. Looks like it can find the schema. It is dying
just after it loads the index:
{code}
INFO 12:39:45,401 Loading settings from file:/etc/cassandra/cassandra.yaml
DEBUG 12:39:45,623 Syncing log with a period of 1
INFO 12:39:45,623 DiskAccessMode is standard, indexAccessMode is mmap
DEBUG 12:39:45,709 setting auto_bootstrap to false
DEBUG 12:39:45,853 Initializing system.IndexInfo
DEBUG 12:39:45,880 Starting CFS IndexInfo
DEBUG 12:39:45,895 key cache capacity for IndexInfo is 1
DEBUG 12:39:45,896 row cache capacity for IndexInfo is 0
DEBUG 12:39:45,899 Initializing system.Schema
DEBUG 12:39:45,901 Starting CFS Schema
INFO 12:39:45,902 reading saved cache
/var/lib/cassandra/saved_caches/system-Schema-KeyCache
DEBUG 12:39:45,903 completed reading (0 ms; 1 keys) saved cache
/var/lib/cassandra/saved_caches/system-Schema-KeyCache
INFO 12:39:45,920 Opening /var/lib/cassandra/data/system/Schema-f-9
DEBUG 12:39:45,920 Load statistics for /var/lib/cassandra/data/system/Schema-f-9
INFO 12:39:45,935 JNA not found. Native methods will be disabled.
DEBUG 12:39:45,961 INDEX LOAD TIME for
/var/lib/cassandra/data/system/Schema-f-9: 41 ms.
DEBUG 12:39:45,962 key cache contains 1/1 keys
DEBUG 12:39:45,962 adding /var/lib/cassandra/data/system/Schema-f-9 to list of
files tracked for system.Schema
DEBUG 12:39:45,962 row cache capacity for Schema is 0
DEBUG 12:39:45,963 Initializing system.Migrations
DEBUG 12:39:45,965 Starting CFS Migrations
INFO 12:39:45,967 Opening /var/lib/cassandra/data/system/Migrations-f-9
DEBUG 12:39:45,967 Load statistics for
/var/lib/cassandra/data/system/Migrations-f-9
DEBUG 12:39:45,969 INDEX LOAD TIME for
/var/lib/cassandra/data/system/Migrations-f-9: 2 ms.
DEBUG 12:39:45,969 key cache contains 0/0 keys
DEBUG 12:39:45,970 adding /var/lib/cassandra/data/system/Migrations-f-9 to list
of files tracked for system.Migrations
DEBUG 12:39:45,970 key cache capacity for Migrations is 1
DEBUG 12:39:45,970 row cache capacity for Migrations is 0
DEBUG 12:39:45,971 Initializing system.LocationInfo
DEBUG 12:39:45,973 Starting CFS LocationInfo
INFO 12:39:45,974 reading saved cache
/var/lib/cassandra/saved_caches/system-LocationInfo-KeyCache
DEBUG 12:39:45,975 completed reading (1 ms; 1 keys) saved cache
/var/lib/cassandra/saved_caches/system-LocationInfo-KeyCache
INFO 12:39:45,986 Opening /var/lib/cassandra/data/system/LocationInfo-f-290
DEBUG 12:39:45,986 Load statistics for
/var/lib/cassandra/data/system/LocationInfo-f-290
DEBUG 12:39:45,989 INDEX LOAD TIME for
/var/lib/cassandra/data/system/LocationInfo-f-290: 3 ms.
DEBUG 12:39:45,989 key cache contains 1/1 keys
INFO 12:39:45,989 Opening /var/lib/cassandra/data/system/LocationInfo-f-291
DEBUG 12:39:45,989 Load statistics for
/var/lib/cassandra/data/system/LocationInfo-f-291
DEBUG 12:39:45,992 INDEX LOAD TIME for
/var/lib/cassandra/data/system/LocationInfo-f-291: 3 ms.
DEBUG 12:39:45,992 key cache contains 1/2 keys
DEBUG 12:39:45,992 adding /var/lib/cassandra/data/system/LocationInfo-f-290 to
list of files tracked for system.LocationInfo
DEBUG 12:39:45,993 adding /var/lib/cassandra/data/system/LocationInfo-f-291 to
list of files tracked for system.LocationInfo
DEBUG 12:39:45,993 row cache capacity for LocationInfo is 0
DEBUG 12:39:45,994 Initializing system.HintsColumnFamily
DEBUG 12:39:45,996 Starting CFS HintsColumnFamily
INFO 12:39:45,997 reading saved cache
/var/lib/cassandra/saved_caches/system-HintsColumnFamily-KeyCache
DEBUG 12:39:45,997 completed reading (1 ms; 1 keys) saved cache
/var/lib/cassandra/saved_caches/system-HintsColumnFamily-KeyCache
DEBUG 12:39:45,998 not including compacted sstable HintsColumnFamily-71
DEBUG 12:39:45,998 not including compacted sstable HintsColumnFamily-71
DEBUG 12:39:45,999 not including compacted sstable HintsColumnFamily-71
DEBUG 12:39:45,999 not including compacted sstable HintsColumnFamily-71
DEBUG 12:39:45,999 not including compacted sstable HintsColumnFamily-71
INFO 12:39:46,000 Opening /var/lib/cassandra/data/system/HintsColumnFamily-f-72
DEBUG 12:39:46,000 Load statistics for
/var/lib/cassandra/data/system/HintsColumnFamily-f-72
DEBUG 12:39:46,002 INDEX LOAD TIME for
/var/lib/cassandra/data/system/HintsColumnFamily-f-72: 2 ms.
DEBUG 12:39:46,003 key cache contains 1/1 keys
INFO 12:39:46,003 Opening /var/lib/cassandra/data/system/HintsColumnFamily-f-73
DEBUG 12:39:46,003 Load statistics for
/var/lib/cassandra/data/system/HintsColumnFamily-f-73
DEBUG 12:39:46,006 INDEX LOAD TIME for
/var/lib/cassandra/data/system/HintsColumnFamily-f-73: 3 ms.
DEBUG 12:39:46,006 key cache contains 2/2 keys
DEBUG 12:39:46,006 adding
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010320#comment-13010320
]
Jonathan Ellis commented on CASSANDRA-2309:
---
the NPE is because it doesn't have metadata for the CF it's trying to
instantiate. you probably need to add some debug statements along that
stacktrace to figure out why.
Also: it looks like you're running with asserts off. That makes it trickier to
debug.
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010322#comment-13010322
]
Jason Harvey commented on CASSANDRA-2309:
-
I should add that sstable2json does work on other sstables from my snapshot,
just not the ones I need it to work on :(
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010324#comment-13010324
]
Jonathan Ellis commented on CASSANDRA-2309:
---
Actually, in your log paste it never starts any non-system CFs. So I return to
my original guess, that it can't find the schema for some reason.
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084707 - /cassandra/trunk/src/java/org/apache/cassandra/gms/VersionedValue.java
Author: jbellis
Date: Wed Mar 23 20:03:02 2011
New Revision: 1084707
URL: http://svn.apache.org/viewvc?rev=1084707view=rev
Log:
add toString
patch by Stu Hood
Modified:
cassandra/trunk/src/java/org/apache/cassandra/gms/VersionedValue.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/gms/VersionedValue.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/gms/VersionedValue.java?rev=1084707r1=1084706r2=1084707view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/gms/VersionedValue.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/gms/VersionedValue.java Wed
Mar 23 20:03:02 2011
@@ -79,6 +79,12 @@ public class VersionedValue implements C
return this.version - value.version;
}
+@Override
+public String toString()
+{
+return Value( + value + , + version + );
+}
+
public static class VersionedValueFactory
{
IPartitioner partitioner;
[jira] [Commented] (CASSANDRA-2339) Repair results in benign Unable to delete error on streaming neighbors
[
https://issues.apache.org/jira/browse/CASSANDRA-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010408#comment-13010408
]
Joaquin Casares commented on CASSANDRA-2339:
I spun up a 3 node cluster, ran stress.py on a node, changed the replication
factor to 3, ran a repair followed by a cleanup and did not see these errors on
any of the machines.
Repair results in benign Unable to delete error on streaming neighbors
Key: CASSANDRA-2339
URL: https://issues.apache.org/jira/browse/CASSANDRA-2339
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.4
Reporter: Jason Harvey
Priority: Minor
Labels: repair
When running a repair on a node, all of the surrounding nodes threw
multitudes of the following errors immediately after they started streaming
for the repair:
{code}
ERROR 23:24:00,494 Unable to delete
/var/lib/cassandra/data/system/LocationInfo-f-21-Data.db (it will be removed
on server restart)
ERROR 23:24:00,495 Unable to delete
/var/lib/cassandra/data/reddit/Hide-f-15-Data.db (it will be removed on
server restart)
ERROR 23:24:00,496 Unable to delete
/var/lib/cassandra/data/reddit/CommentSortsCache-f-21-Data.db (it will be
removed on server restart)
ERROR 23:24:00,496 Unable to delete
/var/lib/cassandra/data/reddit/permacache-f-58-Data.db (it will be removed on
server restart)
ERROR 23:24:00,496 Unable to delete
/var/lib/cassandra/data/reddit/VotesByDay-f-5-Data.db (it will be removed on
server restart)
...
{code}
Interestingly, I checked every file and verified that it *was* actually
removed right around the time these errors were thrown. Double-delete going
on somewhere?
The error didn't appear to cause any problems with the repair.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2339) Repair results in benign Unable to delete error on streaming neighbors
[
https://issues.apache.org/jira/browse/CASSANDRA-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-2339.
---
Resolution: Cannot Reproduce
repair doesn't cause deletes. probably a false correlation.
Repair results in benign Unable to delete error on streaming neighbors
Key: CASSANDRA-2339
URL: https://issues.apache.org/jira/browse/CASSANDRA-2339
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.4
Reporter: Jason Harvey
Priority: Minor
Labels: repair
When running a repair on a node, all of the surrounding nodes threw
multitudes of the following errors immediately after they started streaming
for the repair:
{code}
ERROR 23:24:00,494 Unable to delete
/var/lib/cassandra/data/system/LocationInfo-f-21-Data.db (it will be removed
on server restart)
ERROR 23:24:00,495 Unable to delete
/var/lib/cassandra/data/reddit/Hide-f-15-Data.db (it will be removed on
server restart)
ERROR 23:24:00,496 Unable to delete
/var/lib/cassandra/data/reddit/CommentSortsCache-f-21-Data.db (it will be
removed on server restart)
ERROR 23:24:00,496 Unable to delete
/var/lib/cassandra/data/reddit/permacache-f-58-Data.db (it will be removed on
server restart)
ERROR 23:24:00,496 Unable to delete
/var/lib/cassandra/data/reddit/VotesByDay-f-5-Data.db (it will be removed on
server restart)
...
{code}
Interestingly, I checked every file and verified that it *was* actually
removed right around the time these errors were thrown. Double-delete going
on somewhere?
The error didn't appear to cause any problems with the repair.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084745 - /cassandra/trunk/drivers/py/cql/connection.py
Author: eevans Date: Wed Mar 23 21:17:19 2011 New Revision: 1084745 URL: http://svn.apache.org/viewvc?rev=1084745view=rev Log: tolerate leading whitespace in CQL statements Patch by eevans Modified: cassandra/trunk/drivers/py/cql/connection.py Modified: cassandra/trunk/drivers/py/cql/connection.py URL: http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/cql/connection.py?rev=1084745r1=1084744r2=1084745view=diff == --- cassandra/trunk/drivers/py/cql/connection.py (original) +++ cassandra/trunk/drivers/py/cql/connection.py Wed Mar 23 21:17:19 2011 @@ -47,7 +47,7 @@ class Connection(object): ... print %s is %s years of age % (r.key, column.age) _keyspace_re = re.compile(USE (\w+);?, re.I | re.M) -_cfamily_re = re.compile(SELECT\s+.+\s+FROM\s+(\w+), re.I | re.M) +_cfamily_re = re.compile(\s+SELECT\s+.+\s+FROM\s+(\w+), re.I | re.M) def __init__(self, host, port=9160, keyspace=None, username=None, password=None, decoder=None):
svn commit: r1084746 - /cassandra/trunk/drivers/py/cql/marshal.py
Author: eevans Date: Wed Mar 23 21:17:23 2011 New Revision: 1084746 URL: http://svn.apache.org/viewvc?rev=1084746view=rev Log: fix buggy timeuuid term marshalling Patch by eevans Modified: cassandra/trunk/drivers/py/cql/marshal.py Modified: cassandra/trunk/drivers/py/cql/marshal.py URL: http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/cql/marshal.py?rev=1084746r1=1084745r2=1084746view=diff == --- cassandra/trunk/drivers/py/cql/marshal.py (original) +++ cassandra/trunk/drivers/py/cql/marshal.py Wed Mar 23 21:17:23 2011 @@ -53,10 +53,7 @@ def marshal(term): elif isinstance(term, str): return '%s' % __escape_quotes(term) elif isinstance(term, UUID): -if term.version == 1: -return timeuuid(\%s\) % str(term) -else: -return str(term) +return str(term) else: return str(term)
svn commit: r1084748 - /cassandra/trunk/test/system/test_cql.py
Author: eevans Date: Wed Mar 23 21:17:36 2011 New Revision: 1084748 URL: http://svn.apache.org/viewvc?rev=1084748view=rev Log: improved timeuuid system test (CQL) Patch by eevans Modified: cassandra/trunk/test/system/test_cql.py Modified: cassandra/trunk/test/system/test_cql.py URL: http://svn.apache.org/viewvc/cassandra/trunk/test/system/test_cql.py?rev=1084748r1=1084747r2=1084748view=diff == --- cassandra/trunk/test/system/test_cql.py (original) +++ cassandra/trunk/test/system/test_cql.py Wed Mar 23 21:17:36 2011 @@ -504,8 +504,20 @@ class TestCql(ThriftTester): ms = uuid1bytes_to_millis(r[0].columns[0].value.bytes) assert ((time.time() * 1e3) - ms) 100, \ new timeuuid not within 100ms of now (UPDATE vs. SELECT) + +uuid_range = [] +update = UPDATE StandardTimeUUID SET ? = ? WHERE KEY = slicetest +for i in range(5): +uuid_range.append(uuid.uuid1()) +conn.execute(update, uuid_range[i], i) + +r = conn.execute( +SELECT ?..? FROM StandardTimeUUID WHERE KEY = slicetest +, uuid_range[0], uuid_range[len(uuid_range)-1]) + +for (i, col) in enumerate(r[0]): +assert uuid_range[i] == col.name -# TODO: slices of timeuuids from cf w/ TimeUUIDType comparator def test_lexical_uuid(self): store and retrieve lexical uuids
svn commit: r1084747 - in /cassandra/trunk: drivers/py/cql/connection.py test/system/test_cql.py
Author: eevans Date: Wed Mar 23 21:17:32 2011 New Revision: 1084747 URL: http://svn.apache.org/viewvc?rev=1084747view=rev Log: refresh schema information (Python CQL driver) Patch by eevans for CASSANDRA-2260 Modified: cassandra/trunk/drivers/py/cql/connection.py cassandra/trunk/test/system/test_cql.py Modified: cassandra/trunk/drivers/py/cql/connection.py URL: http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/cql/connection.py?rev=1084747r1=1084746r2=1084747view=diff == --- cassandra/trunk/drivers/py/cql/connection.py (original) +++ cassandra/trunk/drivers/py/cql/connection.py Wed Mar 23 21:17:32 2011 @@ -117,7 +117,12 @@ class Connection(object): match = Connection._keyspace_re.match(prepared_query) if match: self._cur_keyspace = match.group(1) - + +# If this is a CREATE, then refresh the schema for decoding purposes. +if query.lstrip().upper().startswith(CREATE , 0, 7): +if isinstance(self.decoder, SchemaDecoder): +self.decoder.schema = self.__get_schema() + return prepared_query def execute(self, query, *args, **kwargs): Modified: cassandra/trunk/test/system/test_cql.py URL: http://svn.apache.org/viewvc/cassandra/trunk/test/system/test_cql.py?rev=1084747r1=1084746r2=1084747view=diff == --- cassandra/trunk/test/system/test_cql.py (original) +++ cassandra/trunk/test/system/test_cql.py Wed Mar 23 21:17:32 2011 @@ -465,7 +465,7 @@ class TestCql(ThriftTester): r = conn.execute( SELECT '%s' FROM StandardTimeUUID WHERE KEY = 'uuidtest' % str(timeuuid)) -assert r[0].columns[0].name == timeuuid.bytes +assert r[0].columns[0].name == timeuuid # Tests a node-side conversion from long to UUID. ms = uuid1bytes_to_millis(uuid.uuid1().bytes) @@ -476,7 +476,7 @@ class TestCql(ThriftTester): r = conn.execute( SELECT 'id' FROM StandardTimeUUIDValues WHERE KEY = 'uuidtest' ) -assert uuid1bytes_to_millis(r[0].columns[0].value) == ms +assert uuid1bytes_to_millis(r[0].columns[0].value.bytes) == ms # Tests a node-side conversion from ISO8601 to UUID. conn.execute( @@ -488,7 +488,7 @@ class TestCql(ThriftTester): SELECT 'id2' FROM StandardTimeUUIDValues WHERE KEY = 'uuidtest' ) # 2011-01-31 17:00:00- == 129649320ms -ms = uuid1bytes_to_millis(r[0].columns[0].value) +ms = uuid1bytes_to_millis(r[0].columns[0].value.bytes) assert ms == 129649320, \ %d != 129649320 (2011-01-31 17:00:00-) % ms @@ -501,7 +501,7 @@ class TestCql(ThriftTester): r = conn.execute( SELECT 'id3' FROM StandardTimeUUIDValues WHERE KEY = 'uuidtest' ) -ms = uuid1bytes_to_millis(r[0].columns[0].value) +ms = uuid1bytes_to_millis(r[0].columns[0].value.bytes) assert ((time.time() * 1e3) - ms) 100, \ new timeuuid not within 100ms of now (UPDATE vs. SELECT)
svn commit: r1084755 - /cassandra/trunk/drivers/py/cql/connection.py
Author: eevans Date: Wed Mar 23 21:30:11 2011 New Revision: 1084755 URL: http://svn.apache.org/viewvc?rev=1084755view=rev Log: schema refresh should work for ALTER/DROP too Patch by eevans for CASSANDRA-2260 Modified: cassandra/trunk/drivers/py/cql/connection.py Modified: cassandra/trunk/drivers/py/cql/connection.py URL: http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/cql/connection.py?rev=1084755r1=1084754r2=1084755view=diff == --- cassandra/trunk/drivers/py/cql/connection.py (original) +++ cassandra/trunk/drivers/py/cql/connection.py Wed Mar 23 21:30:11 2011 @@ -48,6 +48,7 @@ class Connection(object): _keyspace_re = re.compile(USE (\w+);?, re.I | re.M) _cfamily_re = re.compile(\s+SELECT\s+.+\s+FROM\s+(\w+), re.I | re.M) +_ddl_re = re.compile(\s+(CREATE|ALTER|DROP)\s+, re.I | re.M) def __init__(self, host, port=9160, keyspace=None, username=None, password=None, decoder=None): @@ -113,13 +114,15 @@ class Connection(object): match = Connection._cfamily_re.match(prepared_query) if match: self._cur_column_family = match.group(1) -else: -match = Connection._keyspace_re.match(prepared_query) -if match: -self._cur_keyspace = match.group(1) +return prepared_query +match = Connection._keyspace_re.match(prepared_query) +if match: +self._cur_keyspace = match.group(1) +return prepared_query # If this is a CREATE, then refresh the schema for decoding purposes. -if query.lstrip().upper().startswith(CREATE , 0, 7): +match = Connection._ddl_re.match(prepared_query) +if match: if isinstance(self.decoder, SchemaDecoder): self.decoder.schema = self.__get_schema()
[jira] [Resolved] (CASSANDRA-2260) Python CQL driver: refresh schema information
[
https://issues.apache.org/jira/browse/CASSANDRA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved CASSANDRA-2260.
---
Resolution: Fixed
Assignee: Eric Evans
committed.
Python CQL driver: refresh schema information
-
Key: CASSANDRA-2260
URL: https://issues.apache.org/jira/browse/CASSANDRA-2260
Project: Cassandra
Issue Type: Improvement
Components: API
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Currently, {{Connection}} instances perform a schema lookup for the result
decoder once during initialization. At a minimum it should be possible to
force a refresh of this schema info, and it may also make sense to
automatically refresh after {{CREATE}}, {{ALTER}}, and {{DROP}} statements
are executed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2345) CLI: Units on show keyspaces output
[
https://issues.apache.org/jira/browse/CASSANDRA-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2345:
---
Attachment: CASSANDRA-2345-v2.patch
CLI: Units on show keyspaces output
---
Key: CASSANDRA-2345
URL: https://issues.apache.org/jira/browse/CASSANDRA-2345
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.5, 0.8
Attachments: CASSANDRA-2345-v2.patch, CASSANDRA-2345.patch
Original Estimate: 0.1h
Remaining Estimate: 0.1h
Memtable thresholds don't give units/designations:
{code}
Memtable thresholds: 0.0375/8/60
{code}
By comparison, cache info fully qualifies the numbers.
{code}
Key cache size / save period: 0.01/14400
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2345) CLI: Units on show keyspaces output
[
https://issues.apache.org/jira/browse/CASSANDRA-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2345:
---
Attachment: CASSANDRA-2345-v2.patch
CLI: Units on show keyspaces output
---
Key: CASSANDRA-2345
URL: https://issues.apache.org/jira/browse/CASSANDRA-2345
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.5, 0.8
Attachments: CASSANDRA-2345-v2.patch, CASSANDRA-2345.patch
Original Estimate: 0.1h
Remaining Estimate: 0.1h
Memtable thresholds don't give units/designations:
{code}
Memtable thresholds: 0.0375/8/60
{code}
By comparison, cache info fully qualifies the numbers.
{code}
Key cache size / save period: 0.01/14400
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2345) CLI: Units on show keyspaces output
[
https://issues.apache.org/jira/browse/CASSANDRA-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2345:
---
Attachment: (was: CASSANDRA-2345-v2.patch)
CLI: Units on show keyspaces output
---
Key: CASSANDRA-2345
URL: https://issues.apache.org/jira/browse/CASSANDRA-2345
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 0.7.5, 0.8
Attachments: CASSANDRA-2345-v2.patch, CASSANDRA-2345.patch
Original Estimate: 0.1h
Remaining Estimate: 0.1h
Memtable thresholds don't give units/designations:
{code}
Memtable thresholds: 0.0375/8/60
{code}
By comparison, cache info fully qualifies the numbers.
{code}
Key cache size / save period: 0.01/14400
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084765 - /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Author: brandonwilliams Date: Wed Mar 23 21:46:58 2011 New Revision: 1084765 URL: http://svn.apache.org/viewvc?rev=1084765view=rev Log: Show units on 'show keyspaces' cli output. Patch by Pavek Yaskevich, reviewed by Jon Hermes for CASSANDRA-2345 Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java?rev=1084765r1=1084764r2=1084765view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java Wed Mar 23 21:46:58 2011 @@ -1319,9 +1319,9 @@ public class CliClient extends CliUserHe } sessionState.out.printf( Columns sorted by: %s%s%n, cf_def.comparator_type, cf_def.column_type.equals(Super) ? / + cf_def.subcomparator_type : ); -sessionState.out.printf( Row cache size / save period: %s/%s%n, cf_def.row_cache_size, cf_def.row_cache_save_period_in_seconds); -sessionState.out.printf( Key cache size / save period: %s/%s%n, cf_def.key_cache_size, cf_def.key_cache_save_period_in_seconds); -sessionState.out.printf( Memtable thresholds: %s/%s/%s%n, +sessionState.out.printf( Row cache size / save period in seconds: %s/%s%n, cf_def.row_cache_size, cf_def.row_cache_save_period_in_seconds); +sessionState.out.printf( Key cache size / save period in seconds: %s/%s%n, cf_def.key_cache_size, cf_def.key_cache_save_period_in_seconds); +sessionState.out.printf( Memtable thresholds: %s/%s/%s (millions of ops/minutes/MB)%n, cf_def.memtable_operations_in_millions, cf_def.memtable_throughput_in_mb, cf_def.memtable_flush_after_mins); sessionState.out.printf( GC grace seconds: %s%n, cf_def.gc_grace_seconds); sessionState.out.printf( Compaction min/max thresholds: %s/%s%n, cf_def.min_compaction_threshold, cf_def.max_compaction_threshold);
[jira] [Created] (CASSANDRA-2371) Removed/Dead Node keeps reappearing
Removed/Dead Node keeps reappearing --- Key: CASSANDRA-2371 URL: https://issues.apache.org/jira/browse/CASSANDRA-2371 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4, 0.7.3 Environment: Large Amazon EC2 instances. Ubuntu 10.04.2 Reporter: techlabs Priority: Minor The removetoken option does not seem to work. The original node 10.240.50.63 comes back into the ring, even after the EC2 instance is no longer in existence. Originally I tried to add a new node 10.214.103.224 with the same token, but there were some complications with that. I have pasted below all the INFO log entries found with greping the system log files. Seems to be a similar issue seen with http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ghost-node-showing-up-in-the-ring-td6198180.html INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner INFO [GossipStage:1] 2011-03-16 17:26:51,083 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:27:24,767 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:29:30,191 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:31:35,609 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:33:39,440 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [GossipStage:1] 2011-03-10 03:52:37,299 Gossiper.java (line 608) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-10 03:52:37,545 Gossiper.java (line 600) InetAddress /10.240.50.63 is now UP INFO [HintedHandoff:1] 2011-03-10 03:53:36,168 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-10 03:53:36,169 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [GossipStage:1] 2011-03-15 23:23:43,770 Gossiper.java (line 623) Node /10.240.50.63 has restarted, now UP again INFO [GossipStage:1] 2011-03-15 23:23:43,771 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [HintedHandoff:1] 2011-03-15 23:28:48,957 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-15 23:28:48,958 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-15 23:37:25,071 Gossiper.java (line 226) InetAddress /10.240.50.63 is now dead. INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner WARN [GossipStage:1] 2011-03-16 00:54:31,590 TokenMetadata.java (line 115) Token 957044156965139000 changing ownership from /10.240.50.63 to /10.214.103.224 INFO [GossipStage:1] 2011-03-18 23:37:09,158 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-23 17:22:55,521 HintedHandOffManager.java (line 210) Deleting any stored hints for 10.240.50.63 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2371) Removed/Dead Node keeps reappearing
[ https://issues.apache.org/jira/browse/CASSANDRA-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2371: -- Fix Version/s: 0.7.5 Assignee: Brandon Williams Removed/Dead Node keeps reappearing --- Key: CASSANDRA-2371 URL: https://issues.apache.org/jira/browse/CASSANDRA-2371 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.3, 0.7.4 Environment: Large Amazon EC2 instances. Ubuntu 10.04.2 Reporter: techlabs Assignee: Brandon Williams Priority: Minor Fix For: 0.7.5 The removetoken option does not seem to work. The original node 10.240.50.63 comes back into the ring, even after the EC2 instance is no longer in existence. Originally I tried to add a new node 10.214.103.224 with the same token, but there were some complications with that. I have pasted below all the INFO log entries found with greping the system log files. Seems to be a similar issue seen with http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ghost-node-showing-up-in-the-ring-td6198180.html INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner INFO [GossipStage:1] 2011-03-16 17:26:51,083 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:27:24,767 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:29:30,191 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:31:35,609 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:33:39,440 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [GossipStage:1] 2011-03-10 03:52:37,299 Gossiper.java (line 608) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-10 03:52:37,545 Gossiper.java (line 600) InetAddress /10.240.50.63 is now UP INFO [HintedHandoff:1] 2011-03-10 03:53:36,168 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-10 03:53:36,169 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [GossipStage:1] 2011-03-15 23:23:43,770 Gossiper.java (line 623) Node /10.240.50.63 has restarted, now UP again INFO [GossipStage:1] 2011-03-15 23:23:43,771 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [HintedHandoff:1] 2011-03-15 23:28:48,957 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-15 23:28:48,958 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-15 23:37:25,071 Gossiper.java (line 226) InetAddress /10.240.50.63 is now dead. INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner WARN [GossipStage:1] 2011-03-16 00:54:31,590 TokenMetadata.java (line 115) Token 957044156965139000 changing ownership from /10.240.50.63 to /10.214.103.224 INFO [GossipStage:1] 2011-03-18 23:37:09,158 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-23 17:22:55,521 HintedHandOffManager.java (line 210) Deleting any stored hints for 10.240.50.63 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2260) Python CQL driver: refresh schema information
[
https://issues.apache.org/jira/browse/CASSANDRA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010489#comment-13010489
]
Hudson commented on CASSANDRA-2260:
---
Integrated in Cassandra #801 (See
[https://hudson.apache.org/hudson/job/Cassandra/801/])
schema refresh should work for ALTER/DROP too
Patch by eevans for CASSANDRA-2260
refresh schema information (Python CQL driver)
Patch by eevans for CASSANDRA-2260
Python CQL driver: refresh schema information
-
Key: CASSANDRA-2260
URL: https://issues.apache.org/jira/browse/CASSANDRA-2260
Project: Cassandra
Issue Type: Improvement
Components: API
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Currently, {{Connection}} instances perform a schema lookup for the result
decoder once during initialization. At a minimum it should be possible to
force a refresh of this schema info, and it may also make sense to
automatically refresh after {{CREATE}}, {{ALTER}}, and {{DROP}} statements
are executed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2260) Python CQL driver: refresh schema information
[
https://issues.apache.org/jira/browse/CASSANDRA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reopened CASSANDRA-2260:
-
Assignee: Brandon Williams (was: Eric Evans)
pytx needs this too.
Python CQL driver: refresh schema information
-
Key: CASSANDRA-2260
URL: https://issues.apache.org/jira/browse/CASSANDRA-2260
Project: Cassandra
Issue Type: Improvement
Components: API
Reporter: Eric Evans
Assignee: Brandon Williams
Priority: Minor
Labels: cql
Currently, {{Connection}} instances perform a schema lookup for the result
decoder once during initialization. At a minimum it should be possible to
force a refresh of this schema info, and it may also make sense to
automatically refresh after {{CREATE}}, {{ALTER}}, and {{DROP}} statements
are executed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1263: -- Attachment: 1263-2.txt Done and done. Push replication factor down to the replication strategy Key: CASSANDRA-1263 URL: https://issues.apache.org/jira/browse/CASSANDRA-1263 Project: Cassandra Issue Type: Task Components: Core Reporter: Jeremy Hanna Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1263-2.txt, 1263-incomplete.txt, 1263.txt Original Estimate: 8h Remaining Estimate: 8h Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place. This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2277) parameter substitution for Java CQL driver
[
https://issues.apache.org/jira/browse/CASSANDRA-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Dusbabek updated CASSANDRA-2277:
-
Attachment: v1-0004-fix-off-by-one-in-CassandraResultSet.txt
v1-0003-compress-utf8-bytes-and-not-platform-bytes.txt
v1-0002-JDBC-PreparedStatements-some-tests.txt
v1-0001-AbstractType-converts-types-to-Strings-not-just-ByteBu.txt
parameter substitution for Java CQL driver
--
Key: CASSANDRA-2277
URL: https://issues.apache.org/jira/browse/CASSANDRA-2277
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Eric Evans
Assignee: Gary Dusbabek
Labels: cql
Fix For: 0.8
Attachments:
v1-0001-AbstractType-converts-types-to-Strings-not-just-ByteBu.txt,
v1-0002-JDBC-PreparedStatements-some-tests.txt,
v1-0003-compress-utf8-bytes-and-not-platform-bytes.txt,
v1-0004-fix-off-by-one-in-CassandraResultSet.txt
The Java driver should support parameter substitution such that given a query
string and a sequence of arguments, question marks ('?') in the query string
will be substituted with the arguments.
{code:style=Java}
conn.execute(SELECT ?,? FROM Standard1 WHERE KEY = ?, 10, 20, foo)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2309) Scrub resulting in Keys must be written in ascending order exception
[
https://issues.apache.org/jira/browse/CASSANDRA-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010499#comment-13010499
]
Jason Harvey commented on CASSANDRA-2309:
-
Ga. Sstable2json doesn't work in the snapshot directories. Worthy of a new
bug report? Would be nice to at least get a friendly error.
Scrub resulting in Keys must be written in ascending order exception
--
Key: CASSANDRA-2309
URL: https://issues.apache.org/jira/browse/CASSANDRA-2309
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.3, 0.7.4
Reporter: Jason Harvey
Getting the following when I try to scrub. The SSTable causing it is over a
gig. Trying to repro on smaller tables so I have something to upload.
{code}
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,264 CompactionManager.java
(line 543) Reading row at 552076476
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 552) row 6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
DEBUG [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 581) Index doublecheck: row
6c6173745f636f6d6d656e74735f74335f386c387633 is 168 bytes
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
108) Last written key : DecoratedKey(125686934811414729670440675125192621396,
627975726c2833626333626339353363353762313133373331336461303233396438303534312c66692e676f73757065726d6f64656c2e636f6d2f70726f66696c65732f2f6170706c65747265713d313237393332313937363529)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
109) Current key : DecoratedKey(11163129555189411157074346827960371449,
6c6173745f636f6d6d656e74735f74335f386c387633)
INFO [CompactionExecutor:1] 2011-03-10 12:07:13,265 SSTableWriter.java (line
110) Writing into file
/var/lib/cassandra/data/reddit/permacache-tmp-f-168492-Data.db
WARN [CompactionExecutor:1] 2011-03-10 12:07:13,265 CompactionManager.java
(line 599) Non-fatal error reading row (stacktrace follows)
java.io.IOException: Keys must be written in ascending order.
at
org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:111)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:128)
at
org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:591)
at
org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:56)
at
org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:195)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2371) Removed/Dead Node keeps reappearing
[ https://issues.apache.org/jira/browse/CASSANDRA-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2371: Attachment: 2371.txt My guess is what is happening is that after aVeryLongTime when the state is evicted, another gossip round occurs and the state is repopulated. Patch to re-quarantine on eviction to avoid this. Removed/Dead Node keeps reappearing --- Key: CASSANDRA-2371 URL: https://issues.apache.org/jira/browse/CASSANDRA-2371 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.3, 0.7.4 Environment: Large Amazon EC2 instances. Ubuntu 10.04.2 Reporter: techlabs Assignee: Brandon Williams Priority: Minor Fix For: 0.7.5 Attachments: 2371.txt The removetoken option does not seem to work. The original node 10.240.50.63 comes back into the ring, even after the EC2 instance is no longer in existence. Originally I tried to add a new node 10.214.103.224 with the same token, but there were some complications with that. I have pasted below all the INFO log entries found with greping the system log files. Seems to be a similar issue seen with http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ghost-node-showing-up-in-the-ring-td6198180.html INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner INFO [GossipStage:1] 2011-03-16 17:26:51,083 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:27:24,767 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:29:30,191 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:31:35,609 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:33:39,440 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [GossipStage:1] 2011-03-10 03:52:37,299 Gossiper.java (line 608) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-10 03:52:37,545 Gossiper.java (line 600) InetAddress /10.240.50.63 is now UP INFO [HintedHandoff:1] 2011-03-10 03:53:36,168 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-10 03:53:36,169 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [GossipStage:1] 2011-03-15 23:23:43,770 Gossiper.java (line 623) Node /10.240.50.63 has restarted, now UP again INFO [GossipStage:1] 2011-03-15 23:23:43,771 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [HintedHandoff:1] 2011-03-15 23:28:48,957 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-15 23:28:48,958 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-15 23:37:25,071 Gossiper.java (line 226) InetAddress /10.240.50.63 is now dead. INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner WARN [GossipStage:1] 2011-03-16 00:54:31,590 TokenMetadata.java (line 115) Token 957044156965139000 changing ownership from /10.240.50.63 to /10.214.103.224 INFO [GossipStage:1] 2011-03-18 23:37:09,158 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-23 17:22:55,521 HintedHandOffManager.java (line 210) Deleting any stored hints for 10.240.50.63 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2372) JDBC driver will need adjustments post 2311
JDBC driver will need adjustments post 2311 --- Key: CASSANDRA-2372 URL: https://issues.apache.org/jira/browse/CASSANDRA-2372 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Priority: Minor Right now jdbc just assumes keys are always bytes. After CASSANDRA-2311 we'll need to use a comparator that can be derived from client.describe_keyspaces(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2373) Index Out Of Bounds during Validation Compaction (Repair)
Index Out Of Bounds during Validation Compaction (Repair) - Key: CASSANDRA-2373 URL: https://issues.apache.org/jira/browse/CASSANDRA-2373 Project: Cassandra Issue Type: Bug Components: Core Environment: CentOS on EC2 Reporter: Benjamin Coverston Stack Trace is below: ERROR [CompactionExecutor:1] 2011-03-23 19:11:39,488 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.HeapByteBuffer.getInt(Unknown Source) at org.apache.cassandra.db.DeletedColumn.getLocalDeletionTime(DeletedColumn.java:57) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedStandard(ColumnFamilyStore.java:879) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedColumnsOnly(ColumnFamilyStore.java:866) at org.apache.cassandra.db.ColumnFamilyStore.removeDeleted(ColumnFamilyStore.java:857) at org.apache.cassandra.io.PrecompactedRow.init(PrecompactedRow.java:94) at org.apache.cassandra.io.CompactionIterator.getCompactedRow(CompactionIterator.java:147) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:108) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:73) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:822) at org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084802 - in /cassandra/trunk: drivers/py/cql/connection.py test/system/test_cql.py
Author: eevans Date: Wed Mar 23 23:23:23 2011 New Revision: 1084802 URL: http://svn.apache.org/viewvc?rev=1084802view=rev Log: leading whitespace optional (sigh) Patch by eevans Modified: cassandra/trunk/drivers/py/cql/connection.py cassandra/trunk/test/system/test_cql.py Modified: cassandra/trunk/drivers/py/cql/connection.py URL: http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/cql/connection.py?rev=1084802r1=1084801r2=1084802view=diff == --- cassandra/trunk/drivers/py/cql/connection.py (original) +++ cassandra/trunk/drivers/py/cql/connection.py Wed Mar 23 23:23:23 2011 @@ -47,8 +47,8 @@ class Connection(object): ... print %s is %s years of age % (r.key, column.age) _keyspace_re = re.compile(USE (\w+);?, re.I | re.M) -_cfamily_re = re.compile(\s+SELECT\s+.+\s+FROM\s+(\w+), re.I | re.M) -_ddl_re = re.compile(\s+(CREATE|ALTER|DROP)\s+, re.I | re.M) +_cfamily_re = re.compile(\s*SELECT\s+.+\s+FROM\s+[\']?(\w+), re.I | re.M) +_ddl_re = re.compile(\s*(CREATE|ALTER|DROP)\s+, re.I | re.M) def __init__(self, host, port=9160, keyspace=None, username=None, password=None, decoder=None): Modified: cassandra/trunk/test/system/test_cql.py URL: http://svn.apache.org/viewvc/cassandra/trunk/test/system/test_cql.py?rev=1084802r1=1084801r2=1084802view=diff == --- cassandra/trunk/test/system/test_cql.py (original) +++ cassandra/trunk/test/system/test_cql.py Wed Mar 23 23:23:23 2011 @@ -528,7 +528,7 @@ class TestCql(ThriftTester): r = conn.execute(SELECT ? FROM StandardUUID WHERE KEY = 'uuidtest', uid) -assert r[0].columns[0].name == uid.bytes +assert r[0].columns[0].name == uid # TODO: slices of uuids from cf w/ LexicalUUIDType comparator @@ -542,16 +542,16 @@ class TestCql(ThriftTester): conn.execute(UPDATE StandardUtf82 SET ? = v1 WHERE KEY = k1, ¢) r = conn.execute(SELECT * FROM StandardUtf82 WHERE KEY = k1) -assert r[0][0].name == ¢ -assert r[0][1].name == © -assert r[0][2].name == ® -assert r[0][3].name == ¿ +assert r[0][0].name == u¢ +assert r[0][1].name == u© +assert r[0][2].name == u® +assert r[0][3].name == u¿ r = conn.execute(SELECT ?..'' FROM StandardUtf82 WHERE KEY = k1, ©) assert len(r[0]) == 3 -assert r[0][0].name == © -assert r[0][1].name == ® -assert r[0][2].name == ¿ +assert r[0][0].name == u© +assert r[0][1].name == u® +assert r[0][2].name == u¿
svn commit: r1084803 - in /cassandra/trunk: src/java/org/apache/cassandra/cql/Cql.g test/system/test_cql.py
Author: eevans Date: Wed Mar 23 23:23:28 2011 New Revision: 1084803 URL: http://svn.apache.org/viewvc?rev=1084803view=rev Log: negative numerical terms (+ tests) Patch by eevans Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g cassandra/trunk/test/system/test_cql.py Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g?rev=1084803r1=1084802r2=1084803view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g (original) +++ cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g Wed Mar 23 23:23:28 2011 @@ -412,7 +412,7 @@ RANGEOP ; INTEGER -: DIGIT+ +: '-'? DIGIT+ ; /* Normally a lexer only emits one token at a time, but ours is tricked out Modified: cassandra/trunk/test/system/test_cql.py URL: http://svn.apache.org/viewvc/cassandra/trunk/test/system/test_cql.py?rev=1084803r1=1084802r2=1084803view=diff == --- cassandra/trunk/test/system/test_cql.py (original) +++ cassandra/trunk/test/system/test_cql.py Wed Mar 23 23:23:28 2011 @@ -553,6 +553,21 @@ class TestCql(ThriftTester): assert r[0][1].name == u® assert r[0][2].name == u¿ - - +def test_read_write_negative_numerics(self): +reading and writing negative numeric values +conn = init() +for cf in (StandardIntegerA, StandardLongA): +for i in range(10): +conn.execute(UPDATE ? SET ? = ? WHERE KEY = negatives;, + cf, + -(i + 1), + i) +r = conn.execute(SELECT ?..? FROM ? WHERE KEY = negatives;, + -10, + -1, + cf) +assert len(r[0]) == 10, \ +returned %d columns, expected %d % (len(r[0]), 10) +assert r[0][0].name == -10 +assert r[0][9].name == -1
[jira] [Updated] (CASSANDRA-2373) Index Out Of Bounds during Validation Compaction (Repair)
[ https://issues.apache.org/jira/browse/CASSANDRA-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Coverston updated CASSANDRA-2373: -- Affects Version/s: 0.7.3 Index Out Of Bounds during Validation Compaction (Repair) - Key: CASSANDRA-2373 URL: https://issues.apache.org/jira/browse/CASSANDRA-2373 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Environment: CentOS on EC2 Reporter: Benjamin Coverston Stack Trace is below: ERROR [CompactionExecutor:1] 2011-03-23 19:11:39,488 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.HeapByteBuffer.getInt(Unknown Source) at org.apache.cassandra.db.DeletedColumn.getLocalDeletionTime(DeletedColumn.java:57) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedStandard(ColumnFamilyStore.java:879) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedColumnsOnly(ColumnFamilyStore.java:866) at org.apache.cassandra.db.ColumnFamilyStore.removeDeleted(ColumnFamilyStore.java:857) at org.apache.cassandra.io.PrecompactedRow.init(PrecompactedRow.java:94) at org.apache.cassandra.io.CompactionIterator.getCompactedRow(CompactionIterator.java:147) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:108) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:73) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:822) at org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2373) Index Out Of Bounds during Validation Compaction (Repair)
[ https://issues.apache.org/jira/browse/CASSANDRA-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Coverston updated CASSANDRA-2373: -- Affects Version/s: (was: 0.7.3) 0.7.4 Index Out Of Bounds during Validation Compaction (Repair) - Key: CASSANDRA-2373 URL: https://issues.apache.org/jira/browse/CASSANDRA-2373 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Environment: CentOS on EC2 Reporter: Benjamin Coverston Stack Trace is below: ERROR [CompactionExecutor:1] 2011-03-23 19:11:39,488 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.HeapByteBuffer.getInt(Unknown Source) at org.apache.cassandra.db.DeletedColumn.getLocalDeletionTime(DeletedColumn.java:57) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedStandard(ColumnFamilyStore.java:879) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedColumnsOnly(ColumnFamilyStore.java:866) at org.apache.cassandra.db.ColumnFamilyStore.removeDeleted(ColumnFamilyStore.java:857) at org.apache.cassandra.io.PrecompactedRow.init(PrecompactedRow.java:94) at org.apache.cassandra.io.CompactionIterator.getCompactedRow(CompactionIterator.java:147) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:108) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:73) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:822) at org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2374) baseline CQL drivers at version 1.0.0
baseline CQL drivers at version 1.0.0 - Key: CASSANDRA-2374 URL: https://issues.apache.org/jira/browse/CASSANDRA-2374 Project: Cassandra Issue Type: Improvement Components: API, Packaging Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8 CQL driver versions will advance at their own pace, but should start out at 1.0.0 for this initial release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2374) baseline CQL drivers at version 1.0.0
[ https://issues.apache.org/jira/browse/CASSANDRA-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2374: -- Attachment: v1-0001-CASSANDRA-2374-baseline-driver-versions-at-1.0.0.txt baseline CQL drivers at version 1.0.0 - Key: CASSANDRA-2374 URL: https://issues.apache.org/jira/browse/CASSANDRA-2374 Project: Cassandra Issue Type: Improvement Components: API, Packaging Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 0.8 Attachments: v1-0001-CASSANDRA-2374-baseline-driver-versions-at-1.0.0.txt CQL driver versions will advance at their own pace, but should start out at 1.0.0 for this initial release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2371) Removed/Dead Node keeps reappearing
[ https://issues.apache.org/jira/browse/CASSANDRA-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2371: -- Attachment: v1-0001-CASSANDRA-2371-baseline-driver-versions-at-1.0.0.txt Removed/Dead Node keeps reappearing --- Key: CASSANDRA-2371 URL: https://issues.apache.org/jira/browse/CASSANDRA-2371 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.3, 0.7.4 Environment: Large Amazon EC2 instances. Ubuntu 10.04.2 Reporter: techlabs Assignee: Brandon Williams Priority: Minor Fix For: 0.7.5 Attachments: 2371.txt, v1-0001-CASSANDRA-2371-baseline-driver-versions-at-1.0.0.txt The removetoken option does not seem to work. The original node 10.240.50.63 comes back into the ring, even after the EC2 instance is no longer in existence. Originally I tried to add a new node 10.214.103.224 with the same token, but there were some complications with that. I have pasted below all the INFO log entries found with greping the system log files. Seems to be a similar issue seen with http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ghost-node-showing-up-in-the-ring-td6198180.html INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner INFO [GossipStage:1] 2011-03-16 17:26:51,083 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:27:24,767 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:29:30,191 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:31:35,609 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:33:39,440 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [GossipStage:1] 2011-03-10 03:52:37,299 Gossiper.java (line 608) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-10 03:52:37,545 Gossiper.java (line 600) InetAddress /10.240.50.63 is now UP INFO [HintedHandoff:1] 2011-03-10 03:53:36,168 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-10 03:53:36,169 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [GossipStage:1] 2011-03-15 23:23:43,770 Gossiper.java (line 623) Node /10.240.50.63 has restarted, now UP again INFO [GossipStage:1] 2011-03-15 23:23:43,771 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [HintedHandoff:1] 2011-03-15 23:28:48,957 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-15 23:28:48,958 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-15 23:37:25,071 Gossiper.java (line 226) InetAddress /10.240.50.63 is now dead. INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner WARN [GossipStage:1] 2011-03-16 00:54:31,590 TokenMetadata.java (line 115) Token 957044156965139000 changing ownership from /10.240.50.63 to /10.214.103.224 INFO [GossipStage:1] 2011-03-18 23:37:09,158 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-23 17:22:55,521 HintedHandOffManager.java (line 210) Deleting any stored hints for 10.240.50.63 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2371) Removed/Dead Node keeps reappearing
[ https://issues.apache.org/jira/browse/CASSANDRA-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2371: -- Attachment: (was: v1-0001-CASSANDRA-2371-baseline-driver-versions-at-1.0.0.txt) Removed/Dead Node keeps reappearing --- Key: CASSANDRA-2371 URL: https://issues.apache.org/jira/browse/CASSANDRA-2371 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.3, 0.7.4 Environment: Large Amazon EC2 instances. Ubuntu 10.04.2 Reporter: techlabs Assignee: Brandon Williams Priority: Minor Fix For: 0.7.5 Attachments: 2371.txt The removetoken option does not seem to work. The original node 10.240.50.63 comes back into the ring, even after the EC2 instance is no longer in existence. Originally I tried to add a new node 10.214.103.224 with the same token, but there were some complications with that. I have pasted below all the INFO log entries found with greping the system log files. Seems to be a similar issue seen with http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ghost-node-showing-up-in-the-ring-td6198180.html INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner INFO [GossipStage:1] 2011-03-16 17:26:51,083 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:27:24,767 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:29:30,191 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:31:35,609 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-19 17:33:39,440 StorageService.java (line 865) Removing token 957044156965139000 for /10.214.103.224 INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [GossipStage:1] 2011-03-10 03:52:37,299 Gossiper.java (line 608) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-10 03:52:37,545 Gossiper.java (line 600) InetAddress /10.240.50.63 is now UP INFO [HintedHandoff:1] 2011-03-10 03:53:36,168 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-10 03:53:36,169 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [GossipStage:1] 2011-03-15 23:23:43,770 Gossiper.java (line 623) Node /10.240.50.63 has restarted, now UP again INFO [GossipStage:1] 2011-03-15 23:23:43,771 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [HintedHandoff:1] 2011-03-15 23:28:48,957 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.240.50.63 INFO [HintedHandoff:1] 2011-03-15 23:28:48,958 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-15 23:37:25,071 Gossiper.java (line 226) InetAddress /10.240.50.63 is now dead. INFO [GossipStage:1] 2011-03-16 00:54:31,590 StorageService.java (line 745) Nodes /10.214.103.224 and /10.240.50.63 have the same token 957044156965139000. /10.214.103.224 is the new owner WARN [GossipStage:1] 2011-03-16 00:54:31,590 TokenMetadata.java (line 115) Token 957044156965139000 changing ownership from /10.240.50.63 to /10.214.103.224 INFO [GossipStage:1] 2011-03-18 23:37:09,158 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 Gossiper.java (line 610) Node /10.240.50.63 is now part of the cluster INFO [GossipStage:1] 2011-03-21 23:37:10,421 StorageService.java (line 726) Node /10.240.50.63 state jump to normal INFO [GossipStage:1] 2011-03-23 17:22:55,520 StorageService.java (line 865) Removing token 957044156965139000 for /10.240.50.63 INFO [ScheduledTasks:1] 2011-03-23 17:22:55,521 HintedHandOffManager.java (line 210) Deleting any stored hints for 10.240.50.63 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084815 - in /cassandra/trunk: build.xml drivers/py/setup.py drivers/txpy/setup.py
Author: eevans
Date: Thu Mar 24 00:26:56 2011
New Revision: 1084815
URL: http://svn.apache.org/viewvc?rev=1084815view=rev
Log:
baseline driver versions at 1.0.0
Patch by eevans; reviewed by brandon.williams for CASSANDRA-2374
Modified:
cassandra/trunk/build.xml
cassandra/trunk/drivers/py/setup.py
cassandra/trunk/drivers/txpy/setup.py
Modified: cassandra/trunk/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1084815r1=1084814r2=1084815view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Thu Mar 24 00:26:56 2011
@@ -55,6 +55,7 @@
property name=test.distributed.src value=${test.dir}/distributed/
property name=dist.dir value=${build.dir}/dist/
property name=base.version value=0.8.0/
+property name=cql.driver.version value=1.0.0 /
condition property=version value=${base.version}
isset property=release/
/condition
@@ -431,7 +432,7 @@
/jar
!-- CQL driver Jar --
- jar jarfile=${build.dir}/${ant.project.name}-cql-${version}.jar
+ jar
jarfile=${build.dir}/${ant.project.name}-cql-${cql.driver.version}.jar
basedir=${build.classes.cql}
manifest
attribute name=Implementation-Title value=Cassandra/
Modified: cassandra/trunk/drivers/py/setup.py
URL:
http://svn.apache.org/viewvc/cassandra/trunk/drivers/py/setup.py?rev=1084815r1=1084814r2=1084815view=diff
==
--- cassandra/trunk/drivers/py/setup.py (original)
+++ cassandra/trunk/drivers/py/setup.py Thu Mar 24 00:26:56 2011
@@ -20,7 +20,7 @@ from os.path import abspath, join, dirna
setup(
name=cql,
-version=1.0,
+version=1.0.0,
description=Cassandra Query Language driver,
long_description=open(abspath(join(dirname(__file__), 'README'))).read(),
url=http://cassandra.apache.org;,
Modified: cassandra/trunk/drivers/txpy/setup.py
URL:
http://svn.apache.org/viewvc/cassandra/trunk/drivers/txpy/setup.py?rev=1084815r1=1084814r2=1084815view=diff
==
--- cassandra/trunk/drivers/txpy/setup.py (original)
+++ cassandra/trunk/drivers/txpy/setup.py Thu Mar 24 00:26:56 2011
@@ -20,7 +20,7 @@ from os.path import abspath, join, dirna
setup(
name=txcql,
-version=1.0,
+version=1.0.0,
description=Cassandra Query Language driver,
long_description=open(abspath(join(dirname(__file__), 'README'))).read(),
url=http://cassandra.apache.org;,
[jira] [Commented] (CASSANDRA-2373) Index Out Of Bounds during Validation Compaction (Repair)
[ https://issues.apache.org/jira/browse/CASSANDRA-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010528#comment-13010528 ] Jonathan Ellis commented on CASSANDRA-2373: --- Did you scrub first? Index Out Of Bounds during Validation Compaction (Repair) - Key: CASSANDRA-2373 URL: https://issues.apache.org/jira/browse/CASSANDRA-2373 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Environment: CentOS on EC2 Reporter: Benjamin Coverston Stack Trace is below: ERROR [CompactionExecutor:1] 2011-03-23 19:11:39,488 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.HeapByteBuffer.getInt(Unknown Source) at org.apache.cassandra.db.DeletedColumn.getLocalDeletionTime(DeletedColumn.java:57) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedStandard(ColumnFamilyStore.java:879) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedColumnsOnly(ColumnFamilyStore.java:866) at org.apache.cassandra.db.ColumnFamilyStore.removeDeleted(ColumnFamilyStore.java:857) at org.apache.cassandra.io.PrecompactedRow.init(PrecompactedRow.java:94) at org.apache.cassandra.io.CompactionIterator.getCompactedRow(CompactionIterator.java:147) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:108) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:73) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:822) at org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2374) baseline CQL drivers at version 1.0.0
[ https://issues.apache.org/jira/browse/CASSANDRA-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010531#comment-13010531 ] Hudson commented on CASSANDRA-2374: --- Integrated in Cassandra #802 (See [https://hudson.apache.org/hudson/job/Cassandra/802/]) baseline driver versions at 1.0.0 Patch by eevans; reviewed by brandon.williams for CASSANDRA-2374 baseline CQL drivers at version 1.0.0 - Key: CASSANDRA-2374 URL: https://issues.apache.org/jira/browse/CASSANDRA-2374 Project: Cassandra Issue Type: Improvement Components: API, Packaging Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 0.8 Attachments: v1-0001-CASSANDRA-2374-baseline-driver-versions-at-1.0.0.txt CQL driver versions will advance at their own pace, but should start out at 1.0.0 for this initial release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2375) Debian source package is unavailable on www.apache.org/dist
Debian source package is unavailable on www.apache.org/dist
---
Key: CASSANDRA-2375
URL: https://issues.apache.org/jira/browse/CASSANDRA-2375
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 0.7.4, 0.6.12
Environment: Linux vsp08 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16
09:17:34 UTC 2010 x86_64 GNU/Linux
Reporter: Hannes Schmidt
We are repackaging the Debian packages for in-house use with minor
modifications. To do so we need the source package, but as of today I seem to
be unable to install it. Apt-get fails with a 403 when trying to download the
orig tarball:
{noformat}
# apt-get source cassandra=0.6.12
Reading package lists...
Building dependency tree...
Reading state information...
NOTICE: 'cassandra' packaging is maintained in the 'Svn' version control system
at:
https://svn.apache.org/repos/asf/cassandra/trunk
Need to get 8,433kB of source archives.
Get:1 http://www.apache.org/dist/cassandra/debian/ 06x/main cassandra 0.6.12
(dsc) [1,796B]
Err http://www.apache.org/dist/cassandra/debian/ 06x/main cassandra 0.6.12 (tar)
403 Forbidden
Get:2 http://www.apache.org/dist/cassandra/debian/ 06x/main cassandra 0.6.12
(diff) [20B]
Failed to fetch
http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_0.6.12.orig.tar.gz
403 Forbidden
Fetched 1,816B in 0s (43.8kB/s)
E: Failed to fetch some archives.
{noformat}
From looking at mirror indexes the orig. tarball seems to be symlinked to the
release tarball in a different directory. Maybe Apache is configured to not
follow symlinks?
0.7.x is probably also affected but I didn't check.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2375) Debian source package is unavailable on www.apache.org/dist
[
https://issues.apache.org/jira/browse/CASSANDRA-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-2375.
---
Resolution: Duplicate
see CASSANDRA-2370
Debian source package is unavailable on www.apache.org/dist
---
Key: CASSANDRA-2375
URL: https://issues.apache.org/jira/browse/CASSANDRA-2375
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 0.6.12, 0.7.4
Environment: Linux vsp08 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16
09:17:34 UTC 2010 x86_64 GNU/Linux
Reporter: Hannes Schmidt
We are repackaging the Debian packages for in-house use with minor
modifications. To do so we need the source package, but as of today I seem to
be unable to install it. Apt-get fails with a 403 when trying to download the
orig tarball:
{noformat}
# apt-get source cassandra=0.6.12
Reading package lists...
Building dependency tree...
Reading state information...
NOTICE: 'cassandra' packaging is maintained in the 'Svn' version control
system at:
https://svn.apache.org/repos/asf/cassandra/trunk
Need to get 8,433kB of source archives.
Get:1 http://www.apache.org/dist/cassandra/debian/ 06x/main cassandra 0.6.12
(dsc) [1,796B]
Err http://www.apache.org/dist/cassandra/debian/ 06x/main cassandra 0.6.12
(tar)
403 Forbidden
Get:2 http://www.apache.org/dist/cassandra/debian/ 06x/main cassandra 0.6.12
(diff) [20B]
Failed to fetch
http://www.apache.org/dist/cassandra/debian/pool/main/c/cassandra/cassandra_0.6.12.orig.tar.gz
403 Forbidden
Fetched 1,816B in 0s (43.8kB/s)
E: Failed to fetch some archives.
{noformat}
From looking at mirror indexes the orig. tarball seems to be symlinked to the
release tarball in a different directory. Maybe Apache is configured to not
follow symlinks?
0.7.x is probably also affected but I didn't check.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1084830 - /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AntiEntropyService.java
Author: jbellis Date: Thu Mar 24 02:32:26 2011 New Revision: 1084830 URL: http://svn.apache.org/viewvc?rev=1084830view=rev Log: s/Session/Repair session/ Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AntiEntropyService.java Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AntiEntropyService.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AntiEntropyService.java?rev=1084830r1=1084829r2=1084830view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AntiEntropyService.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AntiEntropyService.java Thu Mar 24 02:32:26 2011 @@ -804,7 +804,7 @@ public class AntiEntropyService return; // all requests completed -logger.info(Session + getName() + completed successfully.); +logger.info(Repair session + getName() + completed successfully.); AntiEntropyService.this.sessions.remove(getName()); completed.signalAll(); }
[jira] [Commented] (CASSANDRA-1954) Double-check or replace RRW memtable lock
[
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010549#comment-13010549
]
Jonathan Ellis commented on CASSANDRA-1954:
---
I think we forgot a 3rd goal of the Big Lock: make sure that when a memtable is
full, all the flush threads are busy, and the flush queue is full, we _want to_
block writes so we don't OOM from shoving more data into the heap before we can
finish freeing what is being flushed.
Ideas?
Double-check or replace RRW memtable lock
-
Key: CASSANDRA-1954
URL: https://issues.apache.org/jira/browse/CASSANDRA-1954
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments:
0001-Double-check-in-maybeSwitchMemtable-to-minimize-writeL.txt,
0001-Remove-flusherLock-readLock.patch, 1954-0.7-v2.txt, 1954-v2.txt,
1954_trunk.patch
Original Estimate: 8h
Remaining Estimate: 8h
{quote}...when a Memtable reaches its threshold, up to (all) N write threads
will often notice, and race to acquire the writeLock in order to freeze the
memtable. This means that we do way more writeLock acquisitions than we need
to...{quote}
See CASSANDRA-1930 for backstory, but adding double checking inside a read
lock before trying to re-entrantly acquire the writelock would eliminate most
of these excess writelock acquisitions.
Alternatively, we should explore removing locking from these structures
entirely, and replacing the writeLock acquisition with a per-memtable counter
of active threads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2376) Both name an index iterators cast block offset to int
Both name an index iterators cast block offset to int - Key: CASSANDRA-2376 URL: https://issues.apache.org/jira/browse/CASSANDRA-2376 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.5 This means that performing random access to the end of a large row will not work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2376) Both name an index iterators cast block offset to int
[ https://issues.apache.org/jira/browse/CASSANDRA-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2376: -- Attachment: 2376.txt Patch also unifies skipBytes checking into skipBytesFully even where we really are only skipping an int's worth of bytes. Both name an index iterators cast block offset to int - Key: CASSANDRA-2376 URL: https://issues.apache.org/jira/browse/CASSANDRA-2376 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.5 Attachments: 2376.txt This means that performing random access to the end of a large row will not work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
