[jira] [Commented] (CASSANDRA-4324) Implement Lucene FST in for key index
[ https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414561#comment-13414561 ] Jason Rutherglen commented on CASSANDRA-4324: - Also the last results are for 100,000 keys rather than 1 mil. > Implement Lucene FST in for key index > - > > Key: CASSANDRA-4324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4324 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Rutherglen >Assignee: Jason Rutherglen >Priority: Minor > Fix For: 1.2 > > Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch, > CASSANDRA-4324.patch, lucene-core-4.0-SNAPSHOT.jar > > > The Lucene FST data structure offers a compact and fast system for indexing > Cassandra keys. More keys may be loaded which in turn should seeks faster. > * Update the IndexSummary class to make use of the Lucene FST, overriding the > serialization mechanism. > * Alter SSTableReader to make use of the FST seek mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4324) Implement Lucene FST in for key index
[ https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated CASSANDRA-4324: Attachment: CASSANDRA-4324.patch Reran with sorting the keys: Reran FST: 3,564,246 IndexSummary: 4,399,624 The FST is 19% smaller, if the IndexSummary mem calculation is correct. > Implement Lucene FST in for key index > - > > Key: CASSANDRA-4324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4324 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Rutherglen >Assignee: Jason Rutherglen >Priority: Minor > Fix For: 1.2 > > Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch, > CASSANDRA-4324.patch, lucene-core-4.0-SNAPSHOT.jar > > > The Lucene FST data structure offers a compact and fast system for indexing > Cassandra keys. More keys may be loaded which in turn should seeks faster. > * Update the IndexSummary class to make use of the Lucene FST, overriding the > serialization mechanism. > * Alter SSTableReader to make use of the FST seek mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4324) Implement Lucene FST in for key index
[ https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414558#comment-13414558 ] Jason Rutherglen commented on CASSANDRA-4324: - Can you verify the mem size calculation for the IndexSummary is correct? I realized the keys should be sorted? Where is the code that sorts the keys? > Implement Lucene FST in for key index > - > > Key: CASSANDRA-4324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4324 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Rutherglen >Assignee: Jason Rutherglen >Priority: Minor > Fix For: 1.2 > > Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch, > lucene-core-4.0-SNAPSHOT.jar > > > The Lucene FST data structure offers a compact and fast system for indexing > Cassandra keys. More keys may be loaded which in turn should seeks faster. > * Update the IndexSummary class to make use of the Lucene FST, overriding the > serialization mechanism. > * Alter SSTableReader to make use of the FST seek mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4324) Implement Lucene FST in for key index
[ https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated CASSANDRA-4324: Attachment: lucene-core-4.0-SNAPSHOT.jar CASSANDRA-4324.patch FSTMemUsage compares the memory usage of the FST vs. IndexSummary. On 1 million keys these are the results: FST: 39,032,383 bytes IndexSummary: 43,996,068 bytes A difference of about 4 megabytes. FST w would be far smaller if the MD5 hash was not being applied to the key, eg, it does best to with keys that are sequential so that prefix compression may be applied. To run FSTMemUsage, the lucene-core-4.0-SNAPSHOT.jar needs to be added to the lib/ directory. The patch was generated using 'git diff HEAD~1..HEAD' because 'git diff' after 'git add' did not work. > Implement Lucene FST in for key index > - > > Key: CASSANDRA-4324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4324 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Rutherglen >Assignee: Jason Rutherglen >Priority: Minor > Fix For: 1.2 > > Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch, > lucene-core-4.0-SNAPSHOT.jar > > > The Lucene FST data structure offers a compact and fast system for indexing > Cassandra keys. More keys may be loaded which in turn should seeks faster. > * Update the IndexSummary class to make use of the Lucene FST, overriding the > serialization mechanism. > * Alter SSTableReader to make use of the FST seek mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[2/3] git commit: cqlsh: don't suggest CL.ANY on selects Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4074
cqlsh: don't suggest CL.ANY on selects
Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4074
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9f32efa7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9f32efa7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9f32efa7
Branch: refs/heads/trunk
Commit: 9f32efa727e4298784231a8ebb2d7e3f48630fd0
Parents: 7f6cc5e
Author: Brandon Williams
Authored: Sat Jul 14 16:21:27 2012 -0500
Committer: Brandon Williams
Committed: Sat Jul 14 16:21:27 2012 -0500
--
pylib/cqlshlib/cql3handling.py | 28 ++--
pylib/cqlshlib/cqlhandling.py |6 +-
2 files changed, 23 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9f32efa7/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 1628c66..5099322 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -205,15 +205,15 @@ JUNK ::= /([
\t\r\f\v]+|(--|[/][/])[^\n\r]*([\n\r]|$)|[/][*].*?[*][/])/ ;
|
;
- ::=
- |
- |
- |
- |
- |
- |
- |
- ;
+ ::= cl=(
+ |
+ |
+ |
+ |
+ |
+ |
+ | )
+ ;
::= typename=( | ) ;
@@ -239,6 +239,10 @@ JUNK ::= /([
\t\r\f\v]+|(--|[/][/])[^\n\r]*([\n\r]|$)|[/][*].*?[*][/])/ ;
;
'''
+@completer_for('consistencylevel', 'cl')
+def consistencylevel_cl_completer(ctxt, cass):
+return CqlRuleSet.consistency_levels
+
@completer_for('extendedTerm', 'token')
def token_word_completer(ctxt, cass):
return ['TOKEN(']
@@ -285,7 +289,7 @@ syntax_rules += r'''
;
::= "SELECT"
"FROM" cf=
- ("USING" "CONSISTENCY" )?
+ ("USING" "CONSISTENCY" selcl=)?
("WHERE" )?
("ORDER" "BY" ( ","
)* )?
("LIMIT" )?
@@ -304,6 +308,10 @@ syntax_rules += r'''
;
'''
+@completer_for('selectStatement', 'selcl')
+def select_statement_consistencylevel(ctxt, cass):
+return [cl for cl in CqlRuleSet.consistency_levels if cl != 'ANY']
+
@completer_for('orderByClause', 'ordercol')
def select_order_column_completer(ctxt, cass):
prev_order_cols = ctxt.get_binding('ordercol', ())
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9f32efa7/pylib/cqlshlib/cqlhandling.py
--
diff --git a/pylib/cqlshlib/cqlhandling.py b/pylib/cqlshlib/cqlhandling.py
index aa29c60..715f6f9 100644
--- a/pylib/cqlshlib/cqlhandling.py
+++ b/pylib/cqlshlib/cqlhandling.py
@@ -576,7 +576,7 @@ syntax_rules += r'''
;
::= "SELECT"
"FROM" cf=
- ("USING" "CONSISTENCY" )?
+ ("USING" "CONSISTENCY" selcl=)?
("WHERE" )?
("LIMIT" )?
;
@@ -592,6 +592,10 @@ syntax_rules += r'''
;
'''
+@completer_for('selectStatement', 'selcl')
+def select_statement_consistencylevel(ctxt, cass):
+return [cl for cl in CqlRuleSet.consistency_levels if cl != 'ANY']
+
@completer_for('selectWhereClause', 'keyname')
def select_where_keyname_completer(ctxt, cass):
cfdef = get_cfdef(ctxt, cass)
[3/3] git commit: cqlsh: don't suggest CL.ANY on selects Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4074
cqlsh: don't suggest CL.ANY on selects
Patch by paul cannon, reviewed by brandonwilliams for CASSANDRA-4074
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9f32efa7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9f32efa7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9f32efa7
Branch: refs/heads/cassandra-1.1
Commit: 9f32efa727e4298784231a8ebb2d7e3f48630fd0
Parents: 7f6cc5e
Author: Brandon Williams
Authored: Sat Jul 14 16:21:27 2012 -0500
Committer: Brandon Williams
Committed: Sat Jul 14 16:21:27 2012 -0500
--
pylib/cqlshlib/cql3handling.py | 28 ++--
pylib/cqlshlib/cqlhandling.py |6 +-
2 files changed, 23 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9f32efa7/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 1628c66..5099322 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -205,15 +205,15 @@ JUNK ::= /([
\t\r\f\v]+|(--|[/][/])[^\n\r]*([\n\r]|$)|[/][*].*?[*][/])/ ;
|
;
- ::=
- |
- |
- |
- |
- |
- |
- |
- ;
+ ::= cl=(
+ |
+ |
+ |
+ |
+ |
+ |
+ | )
+ ;
::= typename=( | ) ;
@@ -239,6 +239,10 @@ JUNK ::= /([
\t\r\f\v]+|(--|[/][/])[^\n\r]*([\n\r]|$)|[/][*].*?[*][/])/ ;
;
'''
+@completer_for('consistencylevel', 'cl')
+def consistencylevel_cl_completer(ctxt, cass):
+return CqlRuleSet.consistency_levels
+
@completer_for('extendedTerm', 'token')
def token_word_completer(ctxt, cass):
return ['TOKEN(']
@@ -285,7 +289,7 @@ syntax_rules += r'''
;
::= "SELECT"
"FROM" cf=
- ("USING" "CONSISTENCY" )?
+ ("USING" "CONSISTENCY" selcl=)?
("WHERE" )?
("ORDER" "BY" ( ","
)* )?
("LIMIT" )?
@@ -304,6 +308,10 @@ syntax_rules += r'''
;
'''
+@completer_for('selectStatement', 'selcl')
+def select_statement_consistencylevel(ctxt, cass):
+return [cl for cl in CqlRuleSet.consistency_levels if cl != 'ANY']
+
@completer_for('orderByClause', 'ordercol')
def select_order_column_completer(ctxt, cass):
prev_order_cols = ctxt.get_binding('ordercol', ())
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9f32efa7/pylib/cqlshlib/cqlhandling.py
--
diff --git a/pylib/cqlshlib/cqlhandling.py b/pylib/cqlshlib/cqlhandling.py
index aa29c60..715f6f9 100644
--- a/pylib/cqlshlib/cqlhandling.py
+++ b/pylib/cqlshlib/cqlhandling.py
@@ -576,7 +576,7 @@ syntax_rules += r'''
;
::= "SELECT"
"FROM" cf=
- ("USING" "CONSISTENCY" )?
+ ("USING" "CONSISTENCY" selcl=)?
("WHERE" )?
("LIMIT" )?
;
@@ -592,6 +592,10 @@ syntax_rules += r'''
;
'''
+@completer_for('selectStatement', 'selcl')
+def select_statement_consistencylevel(ctxt, cass):
+return [cl for cl in CqlRuleSet.consistency_levels if cl != 'ANY']
+
@completer_for('selectWhereClause', 'keyname')
def select_where_keyname_completer(ctxt, cass):
cfdef = get_cfdef(ctxt, cass)
[1/3] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 7f6cc5ef6 -> 9f32efa72 refs/heads/trunk 1cb0ad5c4 -> 3c92afdd8 Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c92afdd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c92afdd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c92afdd Branch: refs/heads/trunk Commit: 3c92afdd8a6d75a23e66cb9d26f616b544112e50 Parents: 1cb0ad5 9f32efa Author: Brandon Williams Authored: Sat Jul 14 16:22:14 2012 -0500 Committer: Brandon Williams Committed: Sat Jul 14 16:22:14 2012 -0500 -- pylib/cqlshlib/cql3handling.py | 28 ++-- pylib/cqlshlib/cqlhandling.py |6 +- 2 files changed, 23 insertions(+), 11 deletions(-) --
[jira] [Comment Edited] (CASSANDRA-4434) add COPY TO
[
https://issues.apache.org/jira/browse/CASSANDRA-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414501#comment-13414501
]
Brandon Williams edited comment on CASSANDRA-4434 at 7/14/12 9:05 PM:
--
At a quick glance, I think linesource is only defined for FROM:
{noformat}
cqlsh:Keyspace1> copy "Standard1" to 'foo.csv';
global name 'linesource' is not defined
cqlsh:Keyspace1>
{noformat}
was (Author: brandon.williams):
At a quick glance, I think linesource is only defined for TO:
{noformat}
cqlsh:Keyspace1> copy "Standard1" to 'foo.csv';
global name 'linesource' is not defined
cqlsh:Keyspace1>
{noformat}
> add COPY TO
> ---
>
> Key: CASSANDRA-4434
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4434
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: paul cannon
> Labels: cqlsh
> Fix For: 1.1.3
>
> Attachments: 0001-cqlsh-implement-COPY-TO.patch
>
>
> CASSANDRA-4012 added COPY FROM; this is a ticket to add the inverse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4434) add COPY TO
[
https://issues.apache.org/jira/browse/CASSANDRA-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414501#comment-13414501
]
Brandon Williams commented on CASSANDRA-4434:
-
At a quick glance, I think linesource is only defined for TO:
{noformat}
cqlsh:Keyspace1> copy "Standard1" to 'foo.csv';
global name 'linesource' is not defined
cqlsh:Keyspace1>
{noformat}
> add COPY TO
> ---
>
> Key: CASSANDRA-4434
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4434
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Jonathan Ellis
>Assignee: paul cannon
> Labels: cqlsh
> Fix For: 1.1.3
>
> Attachments: 0001-cqlsh-implement-COPY-TO.patch
>
>
> CASSANDRA-4012 added COPY FROM; this is a ticket to add the inverse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of "Streaming" by Pas
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for
change notification.
The "Streaming" page has been changed by Pas:
http://wiki.apache.org/cassandra/Streaming?action=diff&rev1=7&rev2=8
Comment:
nodetool streams is replaced by nodetool netstats
Monitoring the status of streaming on both Source and Destination nodes can
be found under the `org.apache.cassandra.streaming.StreamingService` MBean.
The `Status` attribute gives an easy indication of what a node is doing with
respect to streaming. The operations `getOutgoingFiles(host)` and
`getIncomingFiles(host)` each return a list of strings describing the status of
individual files being streamed to and from a given host. Each string follows
this format: `[path to file] [bytes sent/received]/[file size]` If you think
that streaming is taking too long on your cluster, the first thing you should
do is check `StreamSources` or `StreamDestinations` to figure out which hosts
are streaming files. Use those hosts as inputs to `getOutgoingFiles()` or
`getIncomingFiles()` to check on the status of individual files from the
problematic source and destination nodes. Streaming is conducted in 32MB
chunks, so you should refresh the file status after a few seconds to see if the
sent/received values change. If they do not change, or change more slowly than
you'd like, something is wrong.
- The streaming status can also be monitored using {{{nodetool -h
streams}}}
+ The streaming status can also be monitored using {{{nodetool -h
-p netstats}}}
[jira] [Commented] (CASSANDRA-4411) Assertion with LCS compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414429#comment-13414429
]
Rudolf VanderLeeden commented on CASSANDRA-4411:
The file assertion.moreinfo.system.log has been attached.
The assertion ERROR could be reproduced by doing the following:
(1) Bulk load 200 SSTables from a snapshot into a new 3-node cluster
(2) Run nodetool compact and repair
(3) Add ~500 SSTables from the same snapshot
(4) Run nodetool repair
RESULT:
- we see immediately a StackOverflowError (from the repair command)
- after 2 minutes compaction starts
- after 11 minutes there is the AssertionError
> Assertion with LCS compaction
> -
>
> Key: CASSANDRA-4411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4411
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.2
>Reporter: Anton Winter
> Fix For: 1.1.3
>
> Attachments: 0001-Add-debugging-info-for-LCS.txt,
> assertion.moreinfo.system.log, system.log
>
>
> As instructed in CASSANDRA-4321 I have raised this issue as a continuation of
> that issue as it appears the problem still exists.
> I have repeatedly run sstablescrub across all my nodes after the 1.1.2
> upgrade until sstablescrub shows no errors. The exceptions described in
> CASSANDRA-4321 do not occur as frequently now but the integrity check still
> throws exceptions on a number of nodes. Once those exceptions occur
> compactionstats shows a large number of pending tasks with no progression
> afterwards.
> {code}
> ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570
> AbstractCassandraDaemon.java (line 134) Exception in thread
> Thread[CompactionExecutor:150,1,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158)
> at
> org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531)
> at
> org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978)
> at
> org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50)
> at
> org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4411) Assertion with LCS compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudolf VanderLeeden updated CASSANDRA-4411:
---
Attachment: assertion.moreinfo.system.log
includes extended INFO lines from using 0001 patch
> Assertion with LCS compaction
> -
>
> Key: CASSANDRA-4411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4411
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.2
>Reporter: Anton Winter
> Fix For: 1.1.3
>
> Attachments: 0001-Add-debugging-info-for-LCS.txt,
> assertion.moreinfo.system.log, system.log
>
>
> As instructed in CASSANDRA-4321 I have raised this issue as a continuation of
> that issue as it appears the problem still exists.
> I have repeatedly run sstablescrub across all my nodes after the 1.1.2
> upgrade until sstablescrub shows no errors. The exceptions described in
> CASSANDRA-4321 do not occur as frequently now but the integrity check still
> throws exceptions on a number of nodes. Once those exceptions occur
> compactionstats shows a large number of pending tasks with no progression
> afterwards.
> {code}
> ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570
> AbstractCassandraDaemon.java (line 134) Exception in thread
> Thread[CompactionExecutor:150,1,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158)
> at
> org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531)
> at
> org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978)
> at
> org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50)
> at
> org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4436) Counters in columns don't preserve correct values after cluster restart
[
https://issues.apache.org/jira/browse/CASSANDRA-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414315#comment-13414315
]
Peter Velas commented on CASSANDRA-4436:
create keyspace test_old
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 2}
and durable_writes = true;
use test_old;
create column family cf1_increment
with column_type = 'Standard'
and comparator = 'BytesType'
and default_validation_class = 'CounterColumnType'
and key_validation_class = 'BytesType'
and read_repair_chance = 1.0
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and caching = 'KEYS_ONLY'
and compression_options = {'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
In version 1.0.10 am always able to reproduce with this steps.. but its not
reproducible in 1.1.2 .
When I stop writing and shutdown node with "nodetool drain" there are some
small commitlog files, but I don't bother to delete them just restart cassandra
process. Maybe this is case ?
> Counters in columns don't preserve correct values after cluster restart
> ---
>
> Key: CASSANDRA-4436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4436
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.10
>Reporter: Peter Velas
>
> Similar to #3821. but affecting normal columns.
> Set up a 2-node cluster with rf=2.
> 1. Create a counter column family and increment a 100 keys in loop 5000
> times.
> 2. Then make a rolling restart to cluster.
> 3. Again increment another 5000 times.
> 4. Make a rolling restart to cluster.
> 5. Again increment another 5000 times.
> 6. Make a rolling restart to cluster.
> After step 6 we were able to reproduce bug with bad counter values.
> Expected values were 15 000. Values returned from cluster are higher then
> 15000 + some random number.
> Rolling restarts are done with nodetool drain. Always waiting until second
> node discover its down then kill java process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
