date:20110706

[jira] [Updated] (CASSANDRA-2843) better performance on long row read

2011-07-06 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-2843:

Attachment: microBenchmark.patch

bq. this implementation should not expect the input always come in already
sorted order

Yeah, that's not really what I said. I said that it should not *assume* it.
Which doesn't mean it cannot optimize for it. If you look at the version I
attached, at least as far a addColumn is concerned, it does the exact same
thing as your version, with the only difference that I first check if adding at
the tail is legit and fail back to a binary search if that is not the case.
That is, as long as the input is in sorted order, it will be as fast as your
implementation (there is one more bytebuffer comparison but I'm willing to bet
that it has no noticeable impact on performance). But it won't create unsorted
CF if the input is not in sorted order.

Btw, Yang, can you try to fix you 3 last comments ?

bq. If the main benefit is avoiding synchronization, shouldn't we just stick w/
TreeMap for simplicity?

I'm attaching a second patch with the micro-benchmark that I've used and the
TreeMap implementation so that people can look for themselves. The test simply
creates a CF, add columns to it (in sorted order) and do a simple iteration at
the end. I've also add a delete at the end because at least in the case of
super columns, we do call removeDeleted so the goal was to see if this has a
significant impact (the deletes are made at the beginning of the CF, which is
the worst case for the ArrayBacked solution). The test also allow to have some
column overwrap (to exercise reconciliation). Not that when that happens, the
input is not in strict sorted order anymore, but it's mostly at the
disadvantage of the ArrayBack implementation there too. Playing with the
parameters (number of columns added, number that overlaps, number of deletes)
the results seems to always be the same. The ArrayBacked is consistently faster
than the TreeMap one that is itself consistently faster than the CSLM one. Now
what I meant is that the difference between ArrayBacked and TreeMap is
generally not as big as the one with CSLM, but it is still often very
noticeable.

This is no surprise in the end, the ArrayBacked solution is optimized for
insertion in sorted order: the insertion is then O(1) and with a small constant
factor because we're using ArrayList. TreeMap can't beat that. Given this, and
given that ColumnFamily is one of our core data structure, I think we should
choose the more efficient implementation for each use case. And truth is, the
ArrayBacked implementation is really not very complicated, that's basic stuff.

bq. That's odd, because adding in sorted order is actually worst-case for CSLM,
and that's what we do on reads.

Yeah, I was a bit quick on that statement. Rerunning my micro-benchmarks does
show that we're much much faster even without reconciliation happening.

better performance on long row read
---

Key: CASSANDRA-2843
URL: https://issues.apache.org/jira/browse/CASSANDRA-2843
Project: Cassandra
Issue Type: New Feature
Reporter: Yang Yang
Attachments: 2843.patch, fast_cf_081_trunk.diff, microBenchmark.patch

[jira] [Commented] (CASSANDRA-2820) Re-introduce FastByteArrayInputStream (and Output equivalent)

2011-07-06 Thread Sylvain Lebresne (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060484#comment-13060484
 ] 

Sylvain Lebresne commented on CASSANDRA-2820:
-

I'm actually not too much of a fan of extending ByteArray*Stream but 
redeclaring all the fields, giving fake argument to the super constructor. 
It's a bit ugly and not too optimal in memory size (the space argument is not a 
huge one I agree). I think we should extend and reuse the protected field of 
the super class. Those are part of the public API, so there is not so much 
liberty over what a future Harmony implementation (or any implementation for 
that matter) can do with them in the future and more importantly, if we 
override all the methods, we don't care (expect for the call to the super 
constructor actually, but it's easy enough to assert the validity of the field 
assignation after the call to super() if we really want to). And talking about 
that, we need to add an implementation of read(byte[]), flush() and 
write(byte[]) because we can't be sure that the implementation we extend will 
not override the ones inherited from InputStream/OutputStream.

Now I'll admit that I made my earlier comment a bit quickly and that in the end 
it may be simpler/cleaner to make FastByteArray*Stream extends 
Input/OutputStream directly and use
{noformat}
InputStream buffer = new FastByteArrayInputStream(bytes);
OutputStream buffer = new FastByteArrayOutputStream(bytes);
{noformat}
We cannot always do that for the OutputStream side because OutputStream doesn't 
have the toByteArray() method, but we can use FastByteArrayOutputStream then. 
Really my earlier comment was more about avoiding to use FastByteArray*Stream 
in more places than strictly necessary.


 Re-introduce FastByteArrayInputStream (and Output equivalent)
 -

 Key: CASSANDRA-2820
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2820
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 0.8.0
 Environment: n/a
Reporter: Paul Loy
Priority: Minor
  Labels: bytearrayinputstream, bytearrayoutputstream, license, 
 synchronized
 Fix For: 1.0

 Attachments: fast_bytearray_iostreams_harmony-patch-2.txt, 
 fast_bytearray_iostreams_harmony-patch-3.txt


 In https://issues.apache.org/jira/browse/CASSANDRA-37 
 FastByteArrayInputStream and FastByteArrayOutputStream were removed due to 
 being code copied from the JDK and then subsequently modified. The JDK 
 license is incompatible with Apache 2 license so the code had to go.
 I have since had a look at the performance of the JDK ByteArrayInputStream 
 and a FastByteArrayInputStream (i.e. one with synchronized methods made 
 un-synchronized) and seen the difference is significant.
 After a warmup-period of 1 loops I get the following for 1 loops 
 through a 128000 byte array:
 bais : 3513ms
 fbais: 72ms
 This varies depending on the OS, machine and Java version, but it's always in 
 favour of the FastByteArrayInputStream as you might expect.
 Then, at Jonathan Ellis' suggestion, I tried this using a modified Apache 
 Harmony ByteArrayInputStream - i.e. one whose license is compatible - and the 
 results were the same. A significant boost.
 I will attach a patch with changes for the 0.8.0 tag.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2863) NPE when writing SSTable generated via repair

2011-07-06 Thread JIRA

NPE when writing SSTable generated via repair
-

 Key: CASSANDRA-2863
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2863
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.1
Reporter: Héctor Izquierdo


A NPE is generated during repair when closing an sstable generated via SSTable 
build. It doesn't happen always. The node had been scrubbed and compacted 
before calling repair.

 INFO [CompactionExecutor:2] 2011-07-06 11:11:32,640 SSTableReader.java (line 
158) Opening /d2/cassandra/data/sbs/walf-g-730
ERROR [CompactionExecutor:2] 2011-07-06 11:11:34,327 
AbstractCassandraDaemon.java (line 113) Fatal exception in thread 
Thread[CompactionExecutor:2,1,main] 
java.lang.NullPointerException
at 
org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.close(SSTableWriter.java:382)
at 
org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:370)
at 
org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315)
at 
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1103)
at 
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1094)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1143352 - in /cassandra/branches/cassandra-0.8: ./ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/db/compaction/ test/unit/org/apache/cassandra/db/compaction/

2011-07-06 Thread slebresne

Author: slebresne
Date: Wed Jul  6 11:34:50 2011
New Revision: 1143352

URL: http://svn.apache.org/viewvc?rev=1143352view=rev
Log:
Handle row tombstones correctly in EchoedRow
patch by slebresne; reviewed by jbellis for CASSANDRA-2786

Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java

cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java

Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1143352r1=1143351r2=1143352view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Wed Jul  6 11:34:50 2011
@@ -15,6 +15,7 @@
  * fix index-building status display (CASSANDRA-2853)
  * fix CLI perpetuating obsolete KsDef.replication_factor (CASSANDRA-2846)
  * improve cli treatment of multiline comments (CASSANDRA-2852)
+ * handle row tombstones correctly in EchoedRow (CASSANDRA-2786)
 
 
 0.8.1

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java?rev=1143352r1=1143351r2=1143352view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java
 Wed Jul  6 11:34:50 2011
@@ -26,6 +26,7 @@ import java.io.IOException;
 import java.security.MessageDigest;
 
 import org.apache.cassandra.db.compaction.AbstractCompactedRow;
+import org.apache.cassandra.db.compaction.CompactionController;
 import org.apache.cassandra.io.sstable.SSTableIdentityIterator;
 
 /**
@@ -35,11 +36,13 @@ import org.apache.cassandra.io.sstable.S
 public class EchoedRow extends AbstractCompactedRow
 {
 private final SSTableIdentityIterator row;
+private final int gcBefore;
 
-public EchoedRow(SSTableIdentityIterator row)
+public EchoedRow(CompactionController controller, SSTableIdentityIterator 
row)
 {
 super(row.getKey());
 this.row = row;
+this.gcBefore = controller.gcBefore;
 // Reset SSTableIdentityIterator because we have not guarantee the 
filePointer hasn't moved since the Iterator was built
 row.reset();
 }
@@ -59,7 +62,7 @@ public class EchoedRow extends AbstractC
 
 public boolean isEmpty()
 {
-return !row.hasNext();
+return !row.hasNext()  
ColumnFamilyStore.removeDeletedCF(row.getColumnFamily(), gcBefore) == null;
 }
 
 public int columnCount()

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java?rev=1143352r1=1143351r2=1143352view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java
 Wed Jul  6 11:34:50 2011
@@ -113,7 +113,7 @@ public class CompactionController
 public AbstractCompactedRow getCompactedRow(ListSSTableIdentityIterator 
rows)
 {
 if (rows.size() == 1  !needDeserialize()  
!shouldPurge(rows.get(0).getKey()))
-return new EchoedRow(rows.get(0));
+return new EchoedRow(this, rows.get(0));
 
 long rowSize = 0;
 for (SSTableIdentityIterator row : rows)

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java?rev=1143352r1=1143351r2=1143352view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
 Wed Jul  6 11:34:50 2011
@@ -412,7 +412,8 @@ public class CompactionManager implement
 // success: perform the compaction
 try
 {
-doCompactionWithoutSizeEstimation(cfs, sstables,

[jira] [Commented] (CASSANDRA-2786) After a minor compaction, deleted key-slices are visible again

2011-07-06 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060524#comment-13060524
 ] 

Hudson commented on CASSANDRA-2786:
---

Integrated in Cassandra-0.8 #205 (See 
[https://builds.apache.org/job/Cassandra-0.8/205/])
Handle row tombstones correctly in EchoedRow
patch by slebresne; reviewed by jbellis for CASSANDRA-2786

slebresne : 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1143352
Files : 
* /cassandra/branches/cassandra-0.8/CHANGES.txt
* 
/cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
* 
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java
* 
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java
* 
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java


 After a minor compaction, deleted key-slices are visible again
 --

 Key: CASSANDRA-2786
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2786
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.0
 Environment: Reproduced on single Cassandra node (CentOS 5.5)
 Reproduced on single Cassandra node (Windows Server 2008)
Reporter: rene kochen
Assignee: Sylvain Lebresne
 Fix For: 0.8.1, 0.8.2

 Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch, 
 2786_part2.patch, CassandraIssue.zip, CassandraIssueJava.zip


 After a minor compaction, deleted key-slices are visible again.
 Steps to reproduce:
 1) Insert a row named test.
 2) Insert 50 rows. During this step, row test is included in a major 
 compaction:
file-1, file-2, file-3 and file-4 compacted to file-5 (includes test).
 3) Delete row named test.
 4) Insert 50 rows. During this step, row test is included in a minor 
 compaction:
file-6, file-7, file-8 and file-9 compacted to file-10 (should include 
 tombstoned test).
 After step 4, row test is live again.
 Test environment:
 Single node with empty database.
 Standard configured super-column-family (I see this behavior with several 
 gc_grace settings (big and small values):
 create column family Customers with column_type = 'Super' and comparator = 
 'BytesType;
 In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the 
 row is still deleted.
 I've included a .NET program to reproduce the problem. I will add a Java 
 version later on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1143372 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/db/compaction/ test/unit/

2011-07-06 Thread slebresne

Author: slebresne
Date: Wed Jul  6 12:17:23 2011
New Revision: 1143372

URL: http://svn.apache.org/viewvc?rev=1143372view=rev
Log:
merge from 0.8

Modified:
cassandra/trunk/   (props changed)
cassandra/trunk/CHANGES.txt
cassandra/trunk/contrib/   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java
   (props changed)
cassandra/trunk/src/java/org/apache/cassandra/db/EchoedRow.java

cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionController.java
cassandra/trunk/test/unit/org/apache/cassandra/Util.java

cassandra/trunk/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java

Propchange: cassandra/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Jul  6 12:17:23 2011
@@ -1,7 +1,7 @@
 
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291
 /cassandra/branches/cassandra-0.7:1026516-1140567,1141129,1141213,1141217
 /cassandra/branches/cassandra-0.7.0:1053690-1055654
-/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1140755,1140760,1141134,1141214,1141220
+/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1140755,1140760,1141134,1141214,1141220,1143352
 /cassandra/branches/cassandra-0.8.0:1125021-1130369
 /cassandra/branches/cassandra-0.8.1:1101014-1125018
 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689

Modified: cassandra/trunk/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1143372r1=1143371r2=1143372view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Wed Jul  6 12:17:23 2011
@@ -26,6 +26,7 @@
(CASSANDRA-2823)
  * Fix race in SystemTable.getCurrentLocalNodeId (CASSANDRA-2824)
  * Correctly set default for replicate_on_write (CASSANDRA-2835)
+ * handle row tombstones correctly in EchoedRow (CASSANDRA-2786)
 
 
 0.8.1

Propchange: cassandra/trunk/contrib/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Jul  6 12:17:23 2011
@@ -1,7 +1,7 @@
 
/cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009
 
/cassandra/branches/cassandra-0.7/contrib:1026516-1140567,1141129,1141213,1141217
 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654
-/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1140755,1140760,1141134,1141214,1141220
+/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1140755,1140760,1141134,1141214,1141220,1143352
 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369
 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018
 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689

Propchange: 
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Jul  6 12:17:23 2011
@@ -1,7 +1,7 @@
 
/cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291
 
/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140567,1141129,1141213,1141217
 
/cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654
-/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1140755,1140760,1141134,1141214,1141220
+/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1140755,1140760,1141134,1141214,1141220,1143352
 
/cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369
 
/cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018
 
/cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689

Propchange: 
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Jul  6

[jira] [Commented] (CASSANDRA-2786) After a minor compaction, deleted key-slices are visible again

2011-07-06 Thread Sylvain Lebresne (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060528#comment-13060528
]

Sylvain Lebresne commented on CASSANDRA-2786:
-

Committed, thanks.

bq. Nit: wouldn't it be cleaner to just pass gcBefore rather than the entire
controller to EchoedRow constructor?

I passed the controller because Precompacted and LazilyCompacted do that too,
so it felt slightly cleaner, and if we happen to need more info from the
controller in the future, it'll be there. But really at the end I did not
change it before committing out of laziness :)

After a minor compaction, deleted key-slices are visible again
--

Key: CASSANDRA-2786
URL: https://issues.apache.org/jira/browse/CASSANDRA-2786
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0
Environment: Reproduced on single Cassandra node (CentOS 5.5)
Reproduced on single Cassandra node (Windows Server 2008)
Reporter: rene kochen
Assignee: Sylvain Lebresne
Fix For: 0.8.1, 0.8.2

Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch,
2786_part2.patch, CassandraIssue.zip, CassandraIssueJava.zip

After a minor compaction, deleted key-slices are visible again.
Steps to reproduce:
1) Insert a row named test.
2) Insert 50 rows. During this step, row test is included in a major
compaction:
file-1, file-2, file-3 and file-4 compacted to file-5 (includes test).
3) Delete row named test.
4) Insert 50 rows. During this step, row test is included in a minor
compaction:
file-6, file-7, file-8 and file-9 compacted to file-10 (should include
tombstoned test).
After step 4, row test is live again.
Test environment:
Single node with empty database.
Standard configured super-column-family (I see this behavior with several
gc_grace settings (big and small values):
create column family Customers with column_type = 'Super' and comparator =
'BytesType;
In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the
row is still deleted.
I've included a .NET program to reproduce the problem. I will add a Java
version later on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2804) expose dropped messages, exceptions over JMX

2011-07-06 Thread Sylvain Lebresne (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060535#comment-13060535
 ] 

Sylvain Lebresne commented on CASSANDRA-2804:
-

In getRecentlyDroppedMessages, the last line of the for loop should be
{noformat}
  lastDropped.put(verb, dropped);
{noformat}
Other than that, +1.

 expose dropped messages, exceptions over JMX
 

 Key: CASSANDRA-2804
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2804
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 0.8.2

 Attachments: 2804-v2.txt, 2804.txt, 
 twttr-cassandra-0.8-counts-resync-droppedmsg-metric.diff


 Patch against 0.7.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

60 matches

Mail list logo