[jira] [Commented] (CASSANDRA-9313) Clarify errors when attempting to write at SERIAL
[
https://issues.apache.org/jira/browse/CASSANDRA-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073614#comment-15073614
]
Wei Deng commented on CASSANDRA-9313:
-
Does this mean the existing documentation here
https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_config_consistency_c.html
is totally inaccurate?
> Clarify errors when attempting to write at SERIAL
> -
>
> Key: CASSANDRA-9313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9313
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Brandon Williams
>Priority: Minor
> Fix For: 2.1.x
>
>
> [LOCAL_]SERIAL does not support writes, but the errors can be very confusing
> if you don't know this:
> {noformat}
> cqlsh:foo> INSERT INTO bar (foo ) VALUES ( 'foo' ) ;
> InvalidRequest: code=2200 [Invalid query] message="You must use conditional
> updates for serializable writes"
> cqlsh:foo> INSERT INTO bar (foo ) VALUES ( 'foo' ) if NOT EXISTS ;
> InvalidRequest: code=2200 [Invalid query] message="SERIAL is not supported as
> conditional update commit consistency. Use ANY if you mean "make sure it is
> accepted but I don't care how many replicas commit it for non-SERIAL reads""
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10947) Remained filed in the hints folder
Gábor Auth created CASSANDRA-10947:
--
Summary: Remained filed in the hints folder
Key: CASSANDRA-10947
URL: https://issues.apache.org/jira/browse/CASSANDRA-10947
Project: Cassandra
Issue Type: Bug
Environment: Cassandra 3.0.0, CentOS 7.2 x64
Reporter: Gábor Auth
I've found a lot of (over 2 million) .crc32 files in the hints folder:
{code}
[data]# du --max-depth=1
7800./saved_caches
271420 ./data
175776 ./commitlog
9219368 ./hints
9674368 .
[data]# ls -1 hints/ | wc -l
2250624
[data]# du hints/
9220336 hints/
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10947) Remained filed in the hints folder
[
https://issues.apache.org/jira/browse/CASSANDRA-10947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073686#comment-15073686
]
Gábor Auth commented on CASSANDRA-10947:
First 10 files:
{code}
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:42
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037542033-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:42
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037752436-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:42
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037762436-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:43
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037772436-1.crc32
-rw-r--r-- 1 cassandra cassandra 7 Nov 20 16:43
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037782437-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:43
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037792437-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:43
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037802437-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:43
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037812437-1.crc32
-rw-r--r-- 1 cassandra cassandra 8 Nov 20 16:43
01e16db3-8b56-4b43-ac7f-b4db9d3b0445-1448037822437-1.crc32
{code}
> Remained filed in the hints folder
> --
>
> Key: CASSANDRA-10947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10947
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.0.0, CentOS 7.2 x64
>Reporter: Gábor Auth
>
> I've found a lot of (over 2 million) .crc32 files in the hints folder:
> {code}
> [data]# du --max-depth=1
> 7800./saved_caches
> 271420 ./data
> 175776 ./commitlog
> 9219368 ./hints
> 9674368 .
> [data]# ls -1 hints/ | wc -l
> 2250624
> [data]# du hints/
> 9220336 hints/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10948) CQLSH error when trying to insert non-ascii statement
Matthieu Nantern created CASSANDRA-10948:
Summary: CQLSH error when trying to insert non-ascii statement
Key: CASSANDRA-10948
URL: https://issues.apache.org/jira/browse/CASSANDRA-10948
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Matthieu Nantern
We recently upgraded Cassandra to v2.2.4 with CQLSH 5.0.1 and we are now unable
to import some CQL file (with French character like 'ê'). It was working on
v2.0.12.
The issue:
{noformat}
Using CQL driver:
Using connect timeout: 5 seconds
Traceback (most recent call last):
File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1110, in onecmd
self.handle_statement(st, statementtext)
File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1135, in
handle_statement
readline.add_history(new_hist)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xea' in position
7192: ordinal not in range(128)
{noformat}
The issue was corrected by changing line 1135 of cqlsh.py (but I don't know if
it's the correct way to do it):
readline.add_history(new_hist) -> readline.add_history(new_hist.encode('utf8'))
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10948) CQLSH error when trying to insert non-ascii statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthieu Nantern updated CASSANDRA-10948:
-
Attachment: patch_CASSANDRA-10948
> CQLSH error when trying to insert non-ascii statement
> -
>
> Key: CASSANDRA-10948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10948
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Matthieu Nantern
> Attachments: patch_CASSANDRA-10948
>
>
> We recently upgraded Cassandra to v2.2.4 with CQLSH 5.0.1 and we are now
> unable to import some CQL file (with French character like 'ê'). It was
> working on v2.0.12.
> The issue:
> {noformat}
> Using CQL driver: '/OPT/cassandra/dsc-cassandra-2.2.4/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/__init__.py'>
> Using connect timeout: 5 seconds
> Traceback (most recent call last):
> File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1110, in onecmd
> self.handle_statement(st, statementtext)
> File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1135, in
> handle_statement
> readline.add_history(new_hist)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xea' in position
> 7192: ordinal not in range(128)
> {noformat}
> The issue was corrected by changing line 1135 of cqlsh.py (but I don't know
> if it's the correct way to do it):
> readline.add_history(new_hist) ->
> readline.add_history(new_hist.encode('utf8'))
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6737) A batch statements on a single partition should not create a new CF object for each update
[ https://issues.apache.org/jira/browse/CASSANDRA-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073752#comment-15073752 ] Martin Grotzke commented on CASSANDRA-6737: --- [~slebresne] Would you say there's any limitation/recommendation regarding the number of statements contained in a single partition batch (or the summarized size in kb)? Does a RowMutation for single partition batch statements become more "expensive" if it contains more statements, e.g. does the heap pressure grow with the number of contained statements? (this question is related to my [comment in CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487?focusedCommentId=15059781&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15059781]) > A batch statements on a single partition should not create a new CF object > for each update > -- > > Key: CASSANDRA-6737 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6737 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Labels: performance > Fix For: 2.0.6 > > Attachments: 6737.2.patch, 6737.txt > > > BatchStatement creates a new ColumnFamily object (as well as a new > RowMutation object) for every update in the batch, even if all those update > are actually on the same partition. This is particularly inefficient when > bulkloading data into a single partition (which is not all that uncommon). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10949) SSTableMultiWriter streaming bug
Marcus Eriksson created CASSANDRA-10949: --- Summary: SSTableMultiWriter streaming bug Key: CASSANDRA-10949 URL: https://issues.apache.org/jira/browse/CASSANDRA-10949 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson Fix For: 3.0.x, 3.x SSTableMultiWriter can create several sstables, if we do create more than one during streaming, the streaming operation will hang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6696) Partition sstables by token range
[ https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073835#comment-15073835 ] Marcus Eriksson commented on CASSANDRA-6696: pushed 2 new commits to the [repo|https://github.com/krummas/cassandra/commits/marcuse/6696-11] - first one fixes a bug where streaming would never finish if we streamed to several sstables (CASSANDRA-10949). The second commit fixes the progress reporting by introducing a writer id that we key on instead of file name, this means that the file name will change in netstats, but the progress will be correct. http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-6696-11-testall http://cassci.datastax.com/view/Dev/view/krummas/job/6696_dtest [~philipthompson] could you have a look at the dtests/ccm changes as well so we can merge them at the same time? https://github.com/krummas/cassandra-dtest/commits/marcuse/6696 and https://github.com/krummas/ccm/commits/multi-data-dirs > Partition sstables by token range > - > > Key: CASSANDRA-6696 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6696 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Marcus Eriksson > Labels: compaction, correctness, dense-storage, > jbod-aware-compaction, performance > Fix For: 3.2 > > > In JBOD, when someone gets a bad drive, the bad drive is replaced with a new > empty one and repair is run. > This can cause deleted data to come back in some cases. Also this is true for > corrupt stables in which we delete the corrupt stable and run repair. > Here is an example: > Say we have 3 nodes A,B and C and RF=3 and GC grace=10days. > row=sankalp col=sankalp is written 20 days back and successfully went to all > three nodes. > Then a delete/tombstone was written successfully for the same row column 15 > days back. > Since this tombstone is more than gc grace, it got compacted in Nodes A and B > since it got compacted with the actual data. So there is no trace of this row > column in node A and B. > Now in node C, say the original data is in drive1 and tombstone is in drive2. > Compaction has not yet reclaimed the data and tombstone. > Drive2 becomes corrupt and was replaced with new empty drive. > Due to the replacement, the tombstone in now gone and row=sankalp col=sankalp > has come back to life. > Now after replacing the drive we run repair. This data will be propagated to > all nodes. > Note: This is still a problem even if we run repair every gc grace. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10948) CQLSH error when trying to insert non-ascii statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073856#comment-15073856
]
Robert Stupp commented on CASSANDRA-10948:
--
Is this a duplicate of CASSANDRA-10875 ?
> CQLSH error when trying to insert non-ascii statement
> -
>
> Key: CASSANDRA-10948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10948
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Matthieu Nantern
> Attachments: patch_CASSANDRA-10948
>
>
> We recently upgraded Cassandra to v2.2.4 with CQLSH 5.0.1 and we are now
> unable to import some CQL file (with French character like 'ê'). It was
> working on v2.0.12.
> The issue:
> {noformat}
> Using CQL driver: '/OPT/cassandra/dsc-cassandra-2.2.4/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/__init__.py'>
> Using connect timeout: 5 seconds
> Traceback (most recent call last):
> File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1110, in onecmd
> self.handle_statement(st, statementtext)
> File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1135, in
> handle_statement
> readline.add_history(new_hist)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xea' in position
> 7192: ordinal not in range(128)
> {noformat}
> The issue was corrected by changing line 1135 of cqlsh.py (but I don't know
> if it's the correct way to do it):
> readline.add_history(new_hist) ->
> readline.add_history(new_hist.encode('utf8'))
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
cassandra git commit: Fix the way we replace sstables after anticompaction
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 f1b9e9a65 -> 0d51b65e3
Fix the way we replace sstables after anticompaction
Patch by marcuse; reviewed by yukim for CASSANDRA-10831
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d51b65e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d51b65e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d51b65e
Branch: refs/heads/cassandra-2.1
Commit: 0d51b65e32bd2c6343d7a07314e0c88256c73bf0
Parents: f1b9e9a
Author: Marcus Eriksson
Authored: Wed Dec 9 13:09:33 2015 +0100
Committer: Marcus Eriksson
Committed: Tue Dec 29 13:45:32 2015 +0100
--
CHANGES.txt| 1 +
.../org/apache/cassandra/db/compaction/CompactionManager.java | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 41bf6bc..9997e1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.13
+ * Fix the way we replace sstables after anticompaction (CASSANDRA-10831)
* cqlsh fails to decode utf-8 characters for text typed columns
(CASSANDRA-10875)
* Log error when stream session fails (CASSANDRA-9294)
* Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 9bddaf5..30b8475 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -503,9 +503,9 @@ public class CompactionManager implements
CompactionManagerMBean
sstableIterator.remove();
}
}
+validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
cfs.getDataTracker().notifySSTableRepairedStatusChanged(mutatedRepairStatuses);
cfs.getDataTracker().unmarkCompacting(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
-validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
if (!sstables.isEmpty())
doAntiCompaction(cfs, ranges, sstables, repairedAt);
}
@@ -1085,6 +1085,7 @@ public class CompactionManager implements
CompactionManagerMBean
int unrepairedKeyCount = 0;
logger.info("Performing anticompaction on {} sstables",
repairedSSTables.size());
// iterate over sstables to check if the repaired / unrepaired ranges
intersect them.
+Set successfullyAntiCompactedSSTables = new HashSet<>();
for (SSTableReader sstable : repairedSSTables)
{
// check that compaction hasn't stolen any sstables used in
previous repair sessions
@@ -1138,7 +1139,7 @@ public class CompactionManager implements
CompactionManagerMBean
}
anticompactedSSTables.addAll(repairedSSTableWriter.finish(repairedAt));
anticompactedSSTables.addAll(unRepairedSSTableWriter.finish(ActiveRepairService.UNREPAIRED_SSTABLE));
-
cfs.getDataTracker().markCompactedSSTablesReplaced(sstableAsSet,
anticompactedSSTables, OperationType.ANTICOMPACTION);
+successfullyAntiCompactedSSTables.add(sstable);
}
catch (Throwable e)
{
@@ -1148,6 +1149,7 @@ public class CompactionManager implements
CompactionManagerMBean
unRepairedSSTableWriter.abort();
}
}
+
cfs.getDataTracker().markCompactedSSTablesReplaced(successfullyAntiCompactedSSTables,
anticompactedSSTables, OperationType.ANTICOMPACTION);
String format = "Repaired {} keys of {} for {}/{}";
logger.debug(format, repairedKeyCount, (repairedKeyCount +
unrepairedKeyCount), cfs.keyspace, cfs.getColumnFamilyName());
String format2 = "Anticompaction completed successfully, anticompacted
from {} to {} sstable(s).";
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/450091bf Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/450091bf Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/450091bf Branch: refs/heads/cassandra-2.2 Commit: 450091bfb8ae66cefa26c2738770d435edf3fb5b Parents: af509ec 0d51b65 Author: Marcus Eriksson Authored: Tue Dec 29 13:46:11 2015 +0100 Committer: Marcus Eriksson Committed: Tue Dec 29 13:46:11 2015 +0100 -- --
[4/4] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b3a8486d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b3a8486d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b3a8486d Branch: refs/heads/trunk Commit: b3a8486d5669abfd6b74400a647ac7db82bf8965 Parents: 6536c05 fe62557 Author: Marcus Eriksson Authored: Tue Dec 29 13:46:53 2015 +0100 Committer: Marcus Eriksson Committed: Tue Dec 29 13:46:53 2015 +0100 -- --
[2/4] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/450091bf Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/450091bf Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/450091bf Branch: refs/heads/trunk Commit: 450091bfb8ae66cefa26c2738770d435edf3fb5b Parents: af509ec 0d51b65 Author: Marcus Eriksson Authored: Tue Dec 29 13:46:11 2015 +0100 Committer: Marcus Eriksson Committed: Tue Dec 29 13:46:11 2015 +0100 -- --
[1/3] cassandra git commit: Fix the way we replace sstables after anticompaction
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 21191e6ef -> fe62557ef
Fix the way we replace sstables after anticompaction
Patch by marcuse; reviewed by yukim for CASSANDRA-10831
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d51b65e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d51b65e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d51b65e
Branch: refs/heads/cassandra-3.0
Commit: 0d51b65e32bd2c6343d7a07314e0c88256c73bf0
Parents: f1b9e9a
Author: Marcus Eriksson
Authored: Wed Dec 9 13:09:33 2015 +0100
Committer: Marcus Eriksson
Committed: Tue Dec 29 13:45:32 2015 +0100
--
CHANGES.txt| 1 +
.../org/apache/cassandra/db/compaction/CompactionManager.java | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 41bf6bc..9997e1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.13
+ * Fix the way we replace sstables after anticompaction (CASSANDRA-10831)
* cqlsh fails to decode utf-8 characters for text typed columns
(CASSANDRA-10875)
* Log error when stream session fails (CASSANDRA-9294)
* Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 9bddaf5..30b8475 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -503,9 +503,9 @@ public class CompactionManager implements
CompactionManagerMBean
sstableIterator.remove();
}
}
+validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
cfs.getDataTracker().notifySSTableRepairedStatusChanged(mutatedRepairStatuses);
cfs.getDataTracker().unmarkCompacting(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
-validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
if (!sstables.isEmpty())
doAntiCompaction(cfs, ranges, sstables, repairedAt);
}
@@ -1085,6 +1085,7 @@ public class CompactionManager implements
CompactionManagerMBean
int unrepairedKeyCount = 0;
logger.info("Performing anticompaction on {} sstables",
repairedSSTables.size());
// iterate over sstables to check if the repaired / unrepaired ranges
intersect them.
+Set successfullyAntiCompactedSSTables = new HashSet<>();
for (SSTableReader sstable : repairedSSTables)
{
// check that compaction hasn't stolen any sstables used in
previous repair sessions
@@ -1138,7 +1139,7 @@ public class CompactionManager implements
CompactionManagerMBean
}
anticompactedSSTables.addAll(repairedSSTableWriter.finish(repairedAt));
anticompactedSSTables.addAll(unRepairedSSTableWriter.finish(ActiveRepairService.UNREPAIRED_SSTABLE));
-
cfs.getDataTracker().markCompactedSSTablesReplaced(sstableAsSet,
anticompactedSSTables, OperationType.ANTICOMPACTION);
+successfullyAntiCompactedSSTables.add(sstable);
}
catch (Throwable e)
{
@@ -1148,6 +1149,7 @@ public class CompactionManager implements
CompactionManagerMBean
unRepairedSSTableWriter.abort();
}
}
+
cfs.getDataTracker().markCompactedSSTablesReplaced(successfullyAntiCompactedSSTables,
anticompactedSSTables, OperationType.ANTICOMPACTION);
String format = "Repaired {} keys of {} for {}/{}";
logger.debug(format, repairedKeyCount, (repairedKeyCount +
unrepairedKeyCount), cfs.keyspace, cfs.getColumnFamilyName());
String format2 = "Anticompaction completed successfully, anticompacted
from {} to {} sstable(s).";
[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fe62557e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fe62557e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fe62557e Branch: refs/heads/cassandra-3.0 Commit: fe62557ef3ec9cc7ed653600f627f9fe1e9876c0 Parents: 21191e6 450091b Author: Marcus Eriksson Authored: Tue Dec 29 13:46:24 2015 +0100 Committer: Marcus Eriksson Committed: Tue Dec 29 13:46:24 2015 +0100 -- --
[1/2] cassandra git commit: Fix the way we replace sstables after anticompaction
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 af509ec9a -> 450091bfb
Fix the way we replace sstables after anticompaction
Patch by marcuse; reviewed by yukim for CASSANDRA-10831
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d51b65e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d51b65e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d51b65e
Branch: refs/heads/cassandra-2.2
Commit: 0d51b65e32bd2c6343d7a07314e0c88256c73bf0
Parents: f1b9e9a
Author: Marcus Eriksson
Authored: Wed Dec 9 13:09:33 2015 +0100
Committer: Marcus Eriksson
Committed: Tue Dec 29 13:45:32 2015 +0100
--
CHANGES.txt| 1 +
.../org/apache/cassandra/db/compaction/CompactionManager.java | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 41bf6bc..9997e1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.13
+ * Fix the way we replace sstables after anticompaction (CASSANDRA-10831)
* cqlsh fails to decode utf-8 characters for text typed columns
(CASSANDRA-10875)
* Log error when stream session fails (CASSANDRA-9294)
* Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 9bddaf5..30b8475 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -503,9 +503,9 @@ public class CompactionManager implements
CompactionManagerMBean
sstableIterator.remove();
}
}
+validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
cfs.getDataTracker().notifySSTableRepairedStatusChanged(mutatedRepairStatuses);
cfs.getDataTracker().unmarkCompacting(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
-validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
if (!sstables.isEmpty())
doAntiCompaction(cfs, ranges, sstables, repairedAt);
}
@@ -1085,6 +1085,7 @@ public class CompactionManager implements
CompactionManagerMBean
int unrepairedKeyCount = 0;
logger.info("Performing anticompaction on {} sstables",
repairedSSTables.size());
// iterate over sstables to check if the repaired / unrepaired ranges
intersect them.
+Set successfullyAntiCompactedSSTables = new HashSet<>();
for (SSTableReader sstable : repairedSSTables)
{
// check that compaction hasn't stolen any sstables used in
previous repair sessions
@@ -1138,7 +1139,7 @@ public class CompactionManager implements
CompactionManagerMBean
}
anticompactedSSTables.addAll(repairedSSTableWriter.finish(repairedAt));
anticompactedSSTables.addAll(unRepairedSSTableWriter.finish(ActiveRepairService.UNREPAIRED_SSTABLE));
-
cfs.getDataTracker().markCompactedSSTablesReplaced(sstableAsSet,
anticompactedSSTables, OperationType.ANTICOMPACTION);
+successfullyAntiCompactedSSTables.add(sstable);
}
catch (Throwable e)
{
@@ -1148,6 +1149,7 @@ public class CompactionManager implements
CompactionManagerMBean
unRepairedSSTableWriter.abort();
}
}
+
cfs.getDataTracker().markCompactedSSTablesReplaced(successfullyAntiCompactedSSTables,
anticompactedSSTables, OperationType.ANTICOMPACTION);
String format = "Repaired {} keys of {} for {}/{}";
logger.debug(format, repairedKeyCount, (repairedKeyCount +
unrepairedKeyCount), cfs.keyspace, cfs.getColumnFamilyName());
String format2 = "Anticompaction completed successfully, anticompacted
from {} to {} sstable(s).";
[2/3] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/450091bf Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/450091bf Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/450091bf Branch: refs/heads/cassandra-3.0 Commit: 450091bfb8ae66cefa26c2738770d435edf3fb5b Parents: af509ec 0d51b65 Author: Marcus Eriksson Authored: Tue Dec 29 13:46:11 2015 +0100 Committer: Marcus Eriksson Committed: Tue Dec 29 13:46:11 2015 +0100 -- --
[1/4] cassandra git commit: Fix the way we replace sstables after anticompaction
Repository: cassandra
Updated Branches:
refs/heads/trunk 6536c05b4 -> b3a8486d5
Fix the way we replace sstables after anticompaction
Patch by marcuse; reviewed by yukim for CASSANDRA-10831
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d51b65e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d51b65e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d51b65e
Branch: refs/heads/trunk
Commit: 0d51b65e32bd2c6343d7a07314e0c88256c73bf0
Parents: f1b9e9a
Author: Marcus Eriksson
Authored: Wed Dec 9 13:09:33 2015 +0100
Committer: Marcus Eriksson
Committed: Tue Dec 29 13:45:32 2015 +0100
--
CHANGES.txt| 1 +
.../org/apache/cassandra/db/compaction/CompactionManager.java | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 41bf6bc..9997e1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.13
+ * Fix the way we replace sstables after anticompaction (CASSANDRA-10831)
* cqlsh fails to decode utf-8 characters for text typed columns
(CASSANDRA-10875)
* Log error when stream session fails (CASSANDRA-9294)
* Fix bugs in commit log archiving startup behavior (CASSANDRA-10593)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d51b65e/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 9bddaf5..30b8475 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -503,9 +503,9 @@ public class CompactionManager implements
CompactionManagerMBean
sstableIterator.remove();
}
}
+validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
cfs.getDataTracker().notifySSTableRepairedStatusChanged(mutatedRepairStatuses);
cfs.getDataTracker().unmarkCompacting(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
-validatedForRepair.release(Sets.union(nonAnticompacting,
mutatedRepairStatuses));
if (!sstables.isEmpty())
doAntiCompaction(cfs, ranges, sstables, repairedAt);
}
@@ -1085,6 +1085,7 @@ public class CompactionManager implements
CompactionManagerMBean
int unrepairedKeyCount = 0;
logger.info("Performing anticompaction on {} sstables",
repairedSSTables.size());
// iterate over sstables to check if the repaired / unrepaired ranges
intersect them.
+Set successfullyAntiCompactedSSTables = new HashSet<>();
for (SSTableReader sstable : repairedSSTables)
{
// check that compaction hasn't stolen any sstables used in
previous repair sessions
@@ -1138,7 +1139,7 @@ public class CompactionManager implements
CompactionManagerMBean
}
anticompactedSSTables.addAll(repairedSSTableWriter.finish(repairedAt));
anticompactedSSTables.addAll(unRepairedSSTableWriter.finish(ActiveRepairService.UNREPAIRED_SSTABLE));
-
cfs.getDataTracker().markCompactedSSTablesReplaced(sstableAsSet,
anticompactedSSTables, OperationType.ANTICOMPACTION);
+successfullyAntiCompactedSSTables.add(sstable);
}
catch (Throwable e)
{
@@ -1148,6 +1149,7 @@ public class CompactionManager implements
CompactionManagerMBean
unRepairedSSTableWriter.abort();
}
}
+
cfs.getDataTracker().markCompactedSSTablesReplaced(successfullyAntiCompactedSSTables,
anticompactedSSTables, OperationType.ANTICOMPACTION);
String format = "Repaired {} keys of {} for {}/{}";
logger.debug(format, repairedKeyCount, (repairedKeyCount +
unrepairedKeyCount), cfs.keyspace, cfs.getColumnFamilyName());
String format2 = "Anticompaction completed successfully, anticompacted
from {} to {} sstable(s).";
[3/4] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fe62557e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fe62557e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fe62557e Branch: refs/heads/trunk Commit: fe62557ef3ec9cc7ed653600f627f9fe1e9876c0 Parents: 21191e6 450091b Author: Marcus Eriksson Authored: Tue Dec 29 13:46:24 2015 +0100 Committer: Marcus Eriksson Committed: Tue Dec 29 13:46:24 2015 +0100 -- --
[jira] [Commented] (CASSANDRA-10948) CQLSH error when trying to insert non-ascii statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073870#comment-15073870
]
Matthieu Nantern commented on CASSANDRA-10948:
--
I don't think so, I tried the proposed patch
(https://issues.apache.org/jira/secure/attachment/12779519/10875-2.1-3.txt) but
I still have the issue
> CQLSH error when trying to insert non-ascii statement
> -
>
> Key: CASSANDRA-10948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10948
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Matthieu Nantern
> Attachments: patch_CASSANDRA-10948
>
>
> We recently upgraded Cassandra to v2.2.4 with CQLSH 5.0.1 and we are now
> unable to import some CQL file (with French character like 'ê'). It was
> working on v2.0.12.
> The issue:
> {noformat}
> Using CQL driver: '/OPT/cassandra/dsc-cassandra-2.2.4/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/__init__.py'>
> Using connect timeout: 5 seconds
> Traceback (most recent call last):
> File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1110, in onecmd
> self.handle_statement(st, statementtext)
> File "/OPT/cassandra/dsc-cassandra/bin/cqlsh.py", line 1135, in
> handle_statement
> readline.add_history(new_hist)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xea' in position
> 7192: ordinal not in range(128)
> {noformat}
> The issue was corrected by changing line 1135 of cqlsh.py (but I don't know
> if it's the correct way to do it):
> readline.add_history(new_hist) ->
> readline.add_history(new_hist.encode('utf8'))
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8755) Replace trivial uses of String.replace/replaceAll/split with StringUtils methods
[ https://issues.apache.org/jira/browse/CASSANDRA-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073924#comment-15073924 ] ASF GitHub Bot commented on CASSANDRA-8755: --- GitHub user alshopov opened a pull request: https://github.com/apache/cassandra/pull/60 Pull request for fixing lhf #CASSANDRA-8755 The discussion for this patch is in JIRA: https://issues.apache.org/jira/browse/CASSANDRA-8755 Currently pull request is for review. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alshopov/cassandra 8755 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cassandra/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit 0d929cbc552a9f76fb34e5976d6094ea18093a83 Author: Alexander Shopov Date: 2015-12-28T12:38:03Z Add unit tests that verify current behavior in order to check changes Signed-off-by: Alexander Shopov commit 2685a2cdb85e9a2f6ae4303e645acafedd77c890 Author: Alexander Shopov Date: 2015-12-29T12:14:50Z Trivial speedups of string operations String.split has fast path for some single char and two char combinations. They fail in cases when the char is regex meta (mainly the '.' character). Use StringUtils.split then. Convert String.replaceAll to static final Pattern-s usage. Less throwaway j.u.r.Patterns by using precompiled versions Replace front and back whitespace removal with trim Remove unused imports from changed files. Signed-off-by: Alexander Shopov > Replace trivial uses of String.replace/replaceAll/split with StringUtils > methods > > > Key: CASSANDRA-8755 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8755 > Project: Cassandra > Issue Type: Improvement >Reporter: Jaroslav Kamenik >Priority: Trivial > Labels: lhf > Attachments: 8755.tar.gz, trunk-8755.patch, trunk-8755.txt > > > There are places in the code where those regex based methods are used with > plain, not regexp, strings, so StringUtils alternatives should be faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8755) Replace trivial uses of String.replace/replaceAll/split with StringUtils methods
[ https://issues.apache.org/jira/browse/CASSANDRA-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073932#comment-15073932 ] Alexander Shopov commented on CASSANDRA-8755: - Current state is in pull request https://github.com/apache/cassandra/pull/60 Two commits - first is unit tests to verify initial behavior. Second is the patch itself - recheck with unit tests. Command to check created tests: -- ant testsome -Dtest.name=org.apache.cassandra.config.CFMetaDataTest -Dtest.methods=testIsNameValidPositive,testIsNameValidNegative ant testsome -Dtest.name=org.apache.cassandra.config.DatabaseDescriptorTest -Dtest.methods=testTokensFromString ant testsome -Dtest.name=org.apache.cassandra.cql3.ColumnIdentifierTest -Dtest.methods=testMaybeQuote ant testsome -Dtest.name=org.apache.cassandra.cql3.statements.PropertyDefinitionsTest -Dtest.methods=testGetBooleanExistant,testGetBooleanNonexistant ant testsome -Dtest.name=org.apache.cassandra.db.marshal.AbstractCompositeTypeTest -Dtest.methods=testEscape,testUnescape ant testsome -Dtest.name=org.apache.cassandra.metrics.CassandraMetricsRegistryTest -Dtest.methods=testChooseType,testMetricName ant testsome -Dtest.name=org.apache.cassandra.cql3.ColumnIdentifierTest -Dtest.methods=testMaybeQuote ant testsome -Dtest.name=org.apache.cassandra.schema.IndexMetadataTest -Dtest.methods=testIsNameValidPositive,testIsNameValidNegative,testGetDefaultIndexName ant testsome -Dtest.name=org.apache.cassandra.utils.CassandraVersionTest -Dtest.methods=testParseIdentifiersPositive,testParseIdentifiersNegative -- No unit tests for: src/java/org/apache/cassandra/db/marshal/TupleType.java src/java/org/apache/cassandra/index/internal/CassandraIndex.java src/java/org/apache/cassandra/service/StorageService.java These seem hard and I have to do quite a bit of mocking an mucking around. Hints welcome. No unit tests for: src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java Testing changes there will need refactoring these classes. They seem very central to Cassandra so I am waiting for advice whether and how to proceed. > Replace trivial uses of String.replace/replaceAll/split with StringUtils > methods > > > Key: CASSANDRA-8755 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8755 > Project: Cassandra > Issue Type: Improvement >Reporter: Jaroslav Kamenik >Priority: Trivial > Labels: lhf > Attachments: 8755.tar.gz, trunk-8755.patch, trunk-8755.txt > > > There are places in the code where those regex based methods are used with > plain, not regexp, strings, so StringUtils alternatives should be faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/52430b93 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/52430b93 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/52430b93 Branch: refs/heads/trunk Commit: 52430b93e502dd44f6f0e1bf097ccaaa45e74fd5 Parents: b3a8486 36608ce Author: Robert Stupp Authored: Tue Dec 29 15:34:17 2015 +0100 Committer: Robert Stupp Committed: Tue Dec 29 15:34:17 2015 +0100 -- CHANGES.txt | 1 + bin/cassandra | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/52430b93/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/52430b93/bin/cassandra --
[1/3] cassandra git commit: jemalloc detection fails due to quoting issues in regex
Repository: cassandra Updated Branches: refs/heads/trunk b3a8486d5 -> 52430b93e jemalloc detection fails due to quoting issues in regex patch by Bernhard K. Weisshuhn; reviewed by Robert Stupp for CASSANDRA-10946 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f9ac6574 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f9ac6574 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f9ac6574 Branch: refs/heads/trunk Commit: f9ac6574561cccd6d829832166ef117ff6b7c5d2 Parents: 450091b Author: Bernhard K. Weisshuhn Authored: Tue Dec 29 15:31:33 2015 +0100 Committer: Robert Stupp Committed: Tue Dec 29 15:31:33 2015 +0100 -- CHANGES.txt | 1 + bin/cassandra | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9ac6574/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 82af7fc..23d6bae 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2.5 + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) * Add new types to Stress (CASSANDRA-9556) http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9ac6574/bin/cassandra -- diff --git a/bin/cassandra b/bin/cassandra index 0bbd9fb..c15c1ab 100755 --- a/bin/cassandra +++ b/bin/cassandra @@ -153,7 +153,7 @@ case "`uname -s`" in which ldconfig > /dev/null 2>&1 if [ $? = 0 ] ; then # e.g. for CentOS -dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v ^$'\t' | sed 's/^\([^:]*\):.*$/\1/'`" +dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v '^\s' | sed 's/^\([^:]*\):.*$/\1/'`" else # e.g. for Debian, OpenSUSE dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf /etc/ld.so.conf.d/*.conf | grep '^/'`"
[2/2] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/36608cef Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/36608cef Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/36608cef Branch: refs/heads/cassandra-3.0 Commit: 36608cefa3470da7aa70a4c3de32d4ed3c3eed3e Parents: fe62557 f9ac657 Author: Robert Stupp Authored: Tue Dec 29 15:34:06 2015 +0100 Committer: Robert Stupp Committed: Tue Dec 29 15:34:06 2015 +0100 -- CHANGES.txt | 1 + bin/cassandra | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/36608cef/CHANGES.txt -- diff --cc CHANGES.txt index b1a556a,23d6bae..837a592 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,14 -1,6 +1,15 @@@ -2.2.5 +3.0.3 + * Implement hints compression (CASSANDRA-9428) + * Fix potential assertion error when reading static columns (CASSANDRA-10903) + * Avoid NoSuchElementException when executing empty batch (CASSANDRA-10711) + * Avoid building PartitionUpdate in toString (CASSANDRA-10897) + * Reduce heap spent when receiving many SSTables (CASSANDRA-10797) + * Add back support for 3rd party auth providers to bulk loader (CASSANDRA-10873) + * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653) + * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes (CASSANDRA-1837) + * Fix sstableloader not working with upper case keyspace name (CASSANDRA-10806) +Merged from 2.2: + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) - * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) * Add new types to Stress (CASSANDRA-9556) * Add property to allow listening on broadcast interface (CASSANDRA-9748)
[2/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/36608cef Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/36608cef Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/36608cef Branch: refs/heads/trunk Commit: 36608cefa3470da7aa70a4c3de32d4ed3c3eed3e Parents: fe62557 f9ac657 Author: Robert Stupp Authored: Tue Dec 29 15:34:06 2015 +0100 Committer: Robert Stupp Committed: Tue Dec 29 15:34:06 2015 +0100 -- CHANGES.txt | 1 + bin/cassandra | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/36608cef/CHANGES.txt -- diff --cc CHANGES.txt index b1a556a,23d6bae..837a592 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,14 -1,6 +1,15 @@@ -2.2.5 +3.0.3 + * Implement hints compression (CASSANDRA-9428) + * Fix potential assertion error when reading static columns (CASSANDRA-10903) + * Avoid NoSuchElementException when executing empty batch (CASSANDRA-10711) + * Avoid building PartitionUpdate in toString (CASSANDRA-10897) + * Reduce heap spent when receiving many SSTables (CASSANDRA-10797) + * Add back support for 3rd party auth providers to bulk loader (CASSANDRA-10873) + * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653) + * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes (CASSANDRA-1837) + * Fix sstableloader not working with upper case keyspace name (CASSANDRA-10806) +Merged from 2.2: + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) - * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) * Add new types to Stress (CASSANDRA-9556) * Add property to allow listening on broadcast interface (CASSANDRA-9748)
cassandra git commit: jemalloc detection fails due to quoting issues in regex
Repository: cassandra Updated Branches: refs/heads/cassandra-2.2 450091bfb -> f9ac65745 jemalloc detection fails due to quoting issues in regex patch by Bernhard K. Weisshuhn; reviewed by Robert Stupp for CASSANDRA-10946 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f9ac6574 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f9ac6574 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f9ac6574 Branch: refs/heads/cassandra-2.2 Commit: f9ac6574561cccd6d829832166ef117ff6b7c5d2 Parents: 450091b Author: Bernhard K. Weisshuhn Authored: Tue Dec 29 15:31:33 2015 +0100 Committer: Robert Stupp Committed: Tue Dec 29 15:31:33 2015 +0100 -- CHANGES.txt | 1 + bin/cassandra | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9ac6574/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 82af7fc..23d6bae 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2.5 + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) * Add new types to Stress (CASSANDRA-9556) http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9ac6574/bin/cassandra -- diff --git a/bin/cassandra b/bin/cassandra index 0bbd9fb..c15c1ab 100755 --- a/bin/cassandra +++ b/bin/cassandra @@ -153,7 +153,7 @@ case "`uname -s`" in which ldconfig > /dev/null 2>&1 if [ $? = 0 ] ; then # e.g. for CentOS -dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v ^$'\t' | sed 's/^\([^:]*\):.*$/\1/'`" +dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v '^\s' | sed 's/^\([^:]*\):.*$/\1/'`" else # e.g. for Debian, OpenSUSE dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf /etc/ld.so.conf.d/*.conf | grep '^/'`"
[1/2] cassandra git commit: jemalloc detection fails due to quoting issues in regex
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 fe62557ef -> 36608cefa jemalloc detection fails due to quoting issues in regex patch by Bernhard K. Weisshuhn; reviewed by Robert Stupp for CASSANDRA-10946 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f9ac6574 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f9ac6574 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f9ac6574 Branch: refs/heads/cassandra-3.0 Commit: f9ac6574561cccd6d829832166ef117ff6b7c5d2 Parents: 450091b Author: Bernhard K. Weisshuhn Authored: Tue Dec 29 15:31:33 2015 +0100 Committer: Robert Stupp Committed: Tue Dec 29 15:31:33 2015 +0100 -- CHANGES.txt | 1 + bin/cassandra | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9ac6574/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 82af7fc..23d6bae 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.2.5 + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) * Add new types to Stress (CASSANDRA-9556) http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9ac6574/bin/cassandra -- diff --git a/bin/cassandra b/bin/cassandra index 0bbd9fb..c15c1ab 100755 --- a/bin/cassandra +++ b/bin/cassandra @@ -153,7 +153,7 @@ case "`uname -s`" in which ldconfig > /dev/null 2>&1 if [ $? = 0 ] ; then # e.g. for CentOS -dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v ^$'\t' | sed 's/^\([^:]*\):.*$/\1/'`" +dirs="/lib64 /lib /usr/lib64 /usr/lib `ldconfig -v 2>/dev/null | grep -v '^\s' | sed 's/^\([^:]*\):.*$/\1/'`" else # e.g. for Debian, OpenSUSE dirs="/lib64 /lib /usr/lib64 /usr/lib `cat /etc/ld.so.conf /etc/ld.so.conf.d/*.conf | grep '^/'`"
[jira] [Resolved] (CASSANDRA-10946) jemalloc detection fails due to quoting issues in regex
[ https://issues.apache.org/jira/browse/CASSANDRA-10946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp resolved CASSANDRA-10946. -- Resolution: Fixed Thanks! Committed as f9ac6574561cccd6d829832166ef117ff6b7c5d2 to 2.2 and merged to 3.0 + trunk > jemalloc detection fails due to quoting issues in regex > --- > > Key: CASSANDRA-10946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10946 > Project: Cassandra > Issue Type: Bug > Components: Configuration, Tools > Environment: ubuntu 14.04 >Reporter: Bernhard K. Weisshuhn >Priority: Minor > Labels: easyfix > Attachments: > 0001-fix-detection-of-jemalloc-on-linux-remove-quoting-is.patch > > > When creating the list of paths where to search for jemalloc, we parse > ldconfig output to get more directories. The current pattern used to filter > out indented rows from ldconfig does not work because of quoting issues of > the involved dollar sign. > I found just changing the regex to '^\s' works and seems less error prone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CASSANDRA-9977) Support counter-columns for native aggregates (sum,avg,max,min)
[
https://issues.apache.org/jira/browse/CASSANDRA-9977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp reopened CASSANDRA-9977:
-
Just realized that the
[merge-commit|https://github.com/apache/cassandra/commit/0858bfbd7b1e2c1ff43baf1ec96a5fadf115e88d]
from 2.2 to 3.0 is empty.
Rebuilt the patch in [this
branch|https://github.com/snazy/cassandra/tree/9977-3.0-post] and submitted [CI
runs|http://cassci.datastax.com/search/?q=snazy-9977-]
[~blerer], can you review this one for 3.0 again?
> Support counter-columns for native aggregates (sum,avg,max,min)
> ---
>
> Key: CASSANDRA-9977
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9977
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Noam Liran
>Assignee: Robert Stupp
> Fix For: 2.2.5, 3.0.3
>
>
> When trying to SUM a column of type COUNTER, this error is returned:
> {noformat}
> InvalidRequest: code=2200 [Invalid query] message="Invalid call to function
> sum, none of its type signatures match (known type signatures: system.sum :
> (tinyint) -> tinyint, system.sum : (smallint) -> smallint, system.sum : (int)
> -> int, system.sum : (bigint) -> bigint, system.sum : (float) -> float,
> system.sum : (double) -> double, system.sum : (decimal) -> decimal,
> system.sum : (varint) -> varint)"
> {noformat}
> This might be relevant for other agg. functions.
> CQL for reproduction:
> {noformat}
> CREATE TABLE test (
> key INT,
> ctr COUNTER,
> PRIMARY KEY (
> key
> )
> );
> UPDATE test SET ctr = ctr + 1 WHERE key = 1;
> SELECT SUM(ctr) FROM test;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7464) Replace sstable2json and json2sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074017#comment-15074017 ] Russell Bradberry commented on CASSANDRA-7464: -- Personally I would like to see an option to have an output method that is more digestible by scripts. The old sstable2json and currently this one, output the entire SSTable as a single array that is pretty-formatted. This is great for visually looking at it but requires the loading of an entire SSTable into memory before JSON parsing it. There are tools that attempt to read a large JSON stream and emit objects as they are complete, but these are rather cumbersome and difficult to use, also tend to be different form language to language. What I would propose is to have a command line option that will output one partition per line (escaping any newlines encountered) without any leading trailing brackets or commas. This will allow for an application to be able to read one partition at a time and work on it in a streaming fashion. I also put my thoughts on this in this github issue: https://github.com/tolbertam/sstable-tools/issues/19 > Replace sstable2json and json2sstable > - > > Key: CASSANDRA-7464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7464 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Chris Lohfink >Priority: Minor > Fix For: 3.x > > Attachments: sstable-only.patch > > > Both tools are pretty awful. They are primarily meant for debugging (there is > much more efficient and convenient ways to do import/export data), but their > output manage to be hard to handle both for humans and for tools (especially > as soon as you have modern stuff like composites). > There is value to having tools to export sstable contents into a format that > is easy to manipulate by human and tools for debugging, small hacks and > general tinkering, but sstable2json and json2sstable are not that. > So I propose that we deprecate those tools and consider writing better > replacements. It shouldn't be too hard to come up with an output format that > is more aware of modern concepts like composites, UDTs, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7464) Replace sstable2json and json2sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074017#comment-15074017 ] Russell Bradberry edited comment on CASSANDRA-7464 at 12/29/15 3:54 PM: I would like to see an option to have an output method that is more digestible by scripts. The old sstable2json and currently this one, output the entire SSTable as a single array that is pretty-formatted. This is great for visually looking at it but requires the loading of an entire SSTable into memory before JSON parsing it. There are tools that attempt to read a large JSON stream and emit objects as they are complete, but these are rather cumbersome and difficult to use, also tend to be different fromm language to language. What I would propose is to have a command line option that will output one partition per line (escaping any newlines encountered) without any leading trailing brackets or commas. This will allow for an application to be able to read one partition at a time and work on it in a streaming fashion. I also put my thoughts on this in this github issue: https://github.com/tolbertam/sstable-tools/issues/19 was (Author: devdazed): Personally I would like to see an option to have an output method that is more digestible by scripts. The old sstable2json and currently this one, output the entire SSTable as a single array that is pretty-formatted. This is great for visually looking at it but requires the loading of an entire SSTable into memory before JSON parsing it. There are tools that attempt to read a large JSON stream and emit objects as they are complete, but these are rather cumbersome and difficult to use, also tend to be different form language to language. What I would propose is to have a command line option that will output one partition per line (escaping any newlines encountered) without any leading trailing brackets or commas. This will allow for an application to be able to read one partition at a time and work on it in a streaming fashion. I also put my thoughts on this in this github issue: https://github.com/tolbertam/sstable-tools/issues/19 > Replace sstable2json and json2sstable > - > > Key: CASSANDRA-7464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7464 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Chris Lohfink >Priority: Minor > Fix For: 3.x > > Attachments: sstable-only.patch > > > Both tools are pretty awful. They are primarily meant for debugging (there is > much more efficient and convenient ways to do import/export data), but their > output manage to be hard to handle both for humans and for tools (especially > as soon as you have modern stuff like composites). > There is value to having tools to export sstable contents into a format that > is easy to manipulate by human and tools for debugging, small hacks and > general tinkering, but sstable2json and json2sstable are not that. > So I propose that we deprecate those tools and consider writing better > replacements. It shouldn't be too hard to come up with an output format that > is more aware of modern concepts like composites, UDTs, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9303) Match cassandra-loader options in COPY FROM
[ https://issues.apache.org/jira/browse/CASSANDRA-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074033#comment-15074033 ] Stefania commented on CASSANDRA-9303: - The hanging tests were caused by the way in which we run cqlsh in ccm, this [pull request|https://github.com/pcmanus/ccm/pull/432] fixed it. The remaining failures were caused by the following two things: * Handling of temporary files is quite different on Windows, the changes to address this are only in the dtest code, see the second commit of the [pull request|https://github.com/riptano/cassandra-dtest/pull/724]. * The path names should have been normalized, see [this commit|https://github.com/stef1927/cassandra/commit/295219dfbcf24ece9729030cce6e9638899b2842]. I've also changed a few more things, mostly discovered whilst trying to reproduce CASSANDRA-10938 on Windows: * Reverted to batching by replica to avoid Cassandra processes using too much CPU. Batching by replica was changed to batching by partition key during the code review of CASSANDRA-9302 because there is a cost in determining the replicas of each record. However, sending batches with records on different replicas is probably worst then spending a few cycles in Python determining the correct replicas. It also allows up to use LOGGED batching, see next point. * Changed batch type from UNLOGGED to LOGGED to avoid a WARN in the Cassandra log files and for more consistent failed batch status reporting (even though INSERT should be idempotent, so this can be changed back to UNLOGGED if performance is impacted too much but it shouldn't since all parititions should be local). * Fixed a problem with cassandra-stress that only manifested on Windows and on trunk when using a custom profile. However the Windows stress launch scripts were incorrect from 2.1 onwards. I worked on the 2.2 patch and merged upwards. I also cherry-picked back to 2.1 with manual conflict resolution in bin/cqlsh. Even though we don't support Windows for 2.1 I figured it was best to fix these problems anyway. > Match cassandra-loader options in COPY FROM > --- > > Key: CASSANDRA-9303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9303 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Critical > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > Attachments: dtest.out > > > https://github.com/brianmhess/cassandra-loader added a bunch of options to > handle real world requirements, we should match those. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10938) test_bulk_round_trip_blogposts is failing occasionally
[ https://issues.apache.org/jira/browse/CASSANDRA-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074037#comment-15074037 ] Stefania commented on CASSANDRA-10938: -- After reverting to batching by replica rather than just by partition key, see discussion on CASSANDRA-9303, the problem becomes very hard to reproduce, about twice out of approximately 50 times. Both failures were on 2.2 HEAD and never on TRUNK despite running about half of the tests on TRUNK. I'm attaching some log files. > test_bulk_round_trip_blogposts is failing occasionally > -- > > Key: CASSANDRA-10938 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10938 > Project: Cassandra > Issue Type: Sub-task > Components: Tools >Reporter: Stefania >Assignee: Stefania > Fix For: 2.1.x > > > We get timeouts occasionally that cause the number of records to be incorrect: > http://cassci.datastax.com/job/trunk_dtest/858/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10938) test_bulk_round_trip_blogposts is failing occasionally
[ https://issues.apache.org/jira/browse/CASSANDRA-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefania updated CASSANDRA-10938: - Attachment: node3_debug.log node2_debug.log node1_debug.log > test_bulk_round_trip_blogposts is failing occasionally > -- > > Key: CASSANDRA-10938 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10938 > Project: Cassandra > Issue Type: Sub-task > Components: Tools >Reporter: Stefania >Assignee: Stefania > Fix For: 2.1.x > > Attachments: node1_debug.log, node2_debug.log, node3_debug.log > > > We get timeouts occasionally that cause the number of records to be incorrect: > http://cassci.datastax.com/job/trunk_dtest/858/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10938) test_bulk_round_trip_blogposts is failing occasionally
[ https://issues.apache.org/jira/browse/CASSANDRA-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074037#comment-15074037 ] Stefania edited comment on CASSANDRA-10938 at 12/29/15 4:19 PM: After reverting to batching by replica rather than just by partition key, see discussion on CASSANDRA-9303, the problem _almost_ disappears. I think there is some other issue, it happened twice all day long and I ran these bulk import tests pretty much all day fixing other issues for CASSANDRA-9303. In both cases the Cassandra processes lock the CPU, both times on 2.2 HEAD despite running several tests on TRUNK as well. I'm attaching some log files. was (Author: stefania): After reverting to batching by replica rather than just by partition key, see discussion on CASSANDRA-9303, the problem becomes very hard to reproduce, about twice out of approximately 50 times. Both failures were on 2.2 HEAD and never on TRUNK despite running about half of the tests on TRUNK. I'm attaching some log files. > test_bulk_round_trip_blogposts is failing occasionally > -- > > Key: CASSANDRA-10938 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10938 > Project: Cassandra > Issue Type: Sub-task > Components: Tools >Reporter: Stefania >Assignee: Stefania > Fix For: 2.1.x > > Attachments: node1_debug.log, node2_debug.log, node3_debug.log > > > We get timeouts occasionally that cause the number of records to be incorrect: > http://cassci.datastax.com/job/trunk_dtest/858/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip_blogposts/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7464) Replace sstable2json and json2sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074017#comment-15074017 ] Russell Bradberry edited comment on CASSANDRA-7464 at 12/29/15 4:27 PM: I would like to see an option to have an output method that is more digestible by scripts. The old sstable2json and currently this one, output the entire SSTable as a single array that is pretty-formatted. This is great for visually looking at it but requires the loading of an entire SSTable into memory before JSON parsing it. There are tools that attempt to read a large JSON stream and emit objects as they are complete, but these are rather cumbersome and difficult to use, also tend to be different from language to language. What I would propose is to have a command line option that will output one partition per line (escaping any newlines encountered) without any leading trailing brackets or commas. This will allow for an application to be able to read one partition at a time and work on it in a streaming fashion. I also put my thoughts on this in this github issue: https://github.com/tolbertam/sstable-tools/issues/19 was (Author: devdazed): I would like to see an option to have an output method that is more digestible by scripts. The old sstable2json and currently this one, output the entire SSTable as a single array that is pretty-formatted. This is great for visually looking at it but requires the loading of an entire SSTable into memory before JSON parsing it. There are tools that attempt to read a large JSON stream and emit objects as they are complete, but these are rather cumbersome and difficult to use, also tend to be different fromm language to language. What I would propose is to have a command line option that will output one partition per line (escaping any newlines encountered) without any leading trailing brackets or commas. This will allow for an application to be able to read one partition at a time and work on it in a streaming fashion. I also put my thoughts on this in this github issue: https://github.com/tolbertam/sstable-tools/issues/19 > Replace sstable2json and json2sstable > - > > Key: CASSANDRA-7464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7464 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Chris Lohfink >Priority: Minor > Fix For: 3.x > > Attachments: sstable-only.patch > > > Both tools are pretty awful. They are primarily meant for debugging (there is > much more efficient and convenient ways to do import/export data), but their > output manage to be hard to handle both for humans and for tools (especially > as soon as you have modern stuff like composites). > There is value to having tools to export sstable contents into a format that > is easy to manipulate by human and tools for debugging, small hacks and > general tinkering, but sstable2json and json2sstable are not that. > So I propose that we deprecate those tools and consider writing better > replacements. It shouldn't be too hard to come up with an output format that > is more aware of modern concepts like composites, UDTs, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10950) Fix HintsCatalogTest
Yuki Morishita created CASSANDRA-10950: -- Summary: Fix HintsCatalogTest Key: CASSANDRA-10950 URL: https://issues.apache.org/jira/browse/CASSANDRA-10950 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Minor Fix For: 3.0.x, 3.x [HintsCatalogTest has been broken|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_testall/331/testReport/] since CASSANDRA-9428 was committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10950) Fix HintsCatalogTest
[ https://issues.apache.org/jira/browse/CASSANDRA-10950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074101#comment-15074101 ] Yuki Morishita commented on CASSANDRA-10950: ||branch||testall||dtest|| |[HintsCatalogTest-fix|https://github.com/yukim/cassandra/tree/HintsCatalogTest-fix]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-HintsCatalogTest-fix-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-HintsCatalogTest-fix-dtest/lastCompletedBuild/testReport/]| (patch is for 3.0) HintsCatalogTest accesses HintsService's static value, and it triggers creation of static singleton (sigh), which tries to load hints from unintended location. > Fix HintsCatalogTest > > > Key: CASSANDRA-10950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10950 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Minor > Fix For: 3.0.x, 3.x > > > [HintsCatalogTest has been > broken|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_testall/331/testReport/] > since CASSANDRA-9428 was committed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: ninja fix to resource leak (CASSANDRA-10708)
Repository: cassandra
Updated Branches:
refs/heads/trunk 52430b93e -> 260163994
ninja fix to resource leak (CASSANDRA-10708)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26016399
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26016399
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26016399
Branch: refs/heads/trunk
Commit: 260163994e4ac71fafb0578cb143ab4f0f22d6ad
Parents: 52430b9
Author: Yuki Morishita
Authored: Tue Dec 29 11:35:10 2015 -0600
Committer: Yuki Morishita
Committed: Tue Dec 29 11:35:10 2015 -0600
--
.../org/apache/cassandra/db/compaction/CompactionManager.java | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/26016399/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index cfffa14..571088b 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -644,15 +644,14 @@ public class CompactionManager implements
CompactionManagerMBean
return;
}
-if(sstable == null)
+if (sstable == null)
{
logger.warn("Will not clean {}, it is not an active sstable",
entry.getValue());
}
else
{
-LifecycleTransaction txn = cfs.getTracker().tryModify(sstable,
OperationType.CLEANUP);
CleanupStrategy cleanupStrategy = CleanupStrategy.get(cfs,
ranges, FBUtilities.nowInSeconds());
-try
+try (LifecycleTransaction txn =
cfs.getTracker().tryModify(sstable, OperationType.CLEANUP))
{
doCleanupOne(cfs, txn, cleanupStrategy, ranges,
hasIndexes);
}
[jira] [Created] (CASSANDRA-10951) Fix ReadCommandTest
Yuki Morishita created CASSANDRA-10951: -- Summary: Fix ReadCommandTest Key: CASSANDRA-10951 URL: https://issues.apache.org/jira/browse/CASSANDRA-10951 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Yuki Morishita Assignee: Yuki Morishita Fix For: 3.x [ReadCommandTest is failing|http://cassci.datastax.com/view/trunk/job/trunk_testall/641/testReport/org.apache.cassandra.db/ReadCommandTest/history/] since CASSANDRA_9975 was merged to trunk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10951) Fix ReadCommandTest
[ https://issues.apache.org/jira/browse/CASSANDRA-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074136#comment-15074136 ] Yuki Morishita commented on CASSANDRA-10951: ||branch||testall||dtest|| |[ReadCommandTest-fix|https://github.com/yukim/cassandra/tree/ReadCommandTest-fix]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-ReadCommandTest-fix-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-ReadCommandTest-fix-dtest/lastCompletedBuild/testReport/]| It looks like ReadCommand is returning value even though stop is signaled. (I'm not familiar with the change in CASSANDRA-9975, so this fix may not be optimal.) > Fix ReadCommandTest > --- > > Key: CASSANDRA-10951 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10951 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Yuki Morishita >Assignee: Yuki Morishita > Fix For: 3.x > > > [ReadCommandTest is > failing|http://cassci.datastax.com/view/trunk/job/trunk_testall/641/testReport/org.apache.cassandra.db/ReadCommandTest/history/] > since CASSANDRA_9975 was merged to trunk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves
[ https://issues.apache.org/jira/browse/CASSANDRA-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-10887: -- Attachment: CASSANDRA_10887_v2.diff > Pending range calculator gives wrong pending ranges for moves > - > > Key: CASSANDRA-10887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10887 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Richard Low >Assignee: sankalp kohli >Priority: Critical > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > Attachments: CASSANDRA-10887.diff, CASSANDRA_10887_v2.diff > > > My understanding is the PendingRangeCalculator is meant to calculate who > should receive extra writes during range movements. However, it adds the > wrong ranges for moves. An extreme example of this can be seen in the > following reproduction. Create a 5 node cluster (I did this on 2.0.16 and > 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and > immediately kill -9 it. Now you see a node as down and moving in the ring. > Try a quorum write for a partition that is stored on that node - it will fail > with a timeout. Further, all CAS reads or writes fail immediately with > unavailable exception because they attempt to include the moving node twice. > This is likely to be the cause of CASSANDRA-10423. > In my example I had this ring: > 127.0.0.1 rack1 Up Normal 170.97 KB 20.00% > -9223372036854775808 > 127.0.0.2 rack1 Up Normal 124.06 KB 20.00% > -5534023222112865485 > 127.0.0.3 rack1 Down Moving 108.7 KB40.00% > 1844674407370955160 > 127.0.0.4 rack1 Up Normal 142.58 KB 0.00% > 1844674407370955161 > 127.0.0.5 rack1 Up Normal 118.64 KB 20.00% > 5534023222112865484 > Node 3 was moving to -1844674407370955160. I added logging to print the > pending and natural endpoints. For ranges owned by node 3, node 3 appeared in > pending and natural endpoints. The blockFor is increased to 3 so we’re > effectively doing CL.ALL operations. This manifests as write timeouts and CAS > unavailables when the node is down. > The correct pending range for this scenario is node 1 is gaining the range > (-1844674407370955160, 1844674407370955160). So node 1 should be added as a > destination for writes and CAS for this range, not node 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves
[ https://issues.apache.org/jira/browse/CASSANDRA-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074169#comment-15074169 ] sankalp kohli commented on CASSANDRA-10887: --- Attaching v2... 1) Added the test for wrap-around interval tests 2) Other tests were not passing since they were not expecting a NetworkTopology. Fixed that. Also I was giving my own custom tokens which was causing others to fail. Changed the test to default tokens(0,10,20...) > Pending range calculator gives wrong pending ranges for moves > - > > Key: CASSANDRA-10887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10887 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Richard Low >Assignee: sankalp kohli >Priority: Critical > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > Attachments: CASSANDRA-10887.diff, CASSANDRA_10887_v2.diff > > > My understanding is the PendingRangeCalculator is meant to calculate who > should receive extra writes during range movements. However, it adds the > wrong ranges for moves. An extreme example of this can be seen in the > following reproduction. Create a 5 node cluster (I did this on 2.0.16 and > 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and > immediately kill -9 it. Now you see a node as down and moving in the ring. > Try a quorum write for a partition that is stored on that node - it will fail > with a timeout. Further, all CAS reads or writes fail immediately with > unavailable exception because they attempt to include the moving node twice. > This is likely to be the cause of CASSANDRA-10423. > In my example I had this ring: > 127.0.0.1 rack1 Up Normal 170.97 KB 20.00% > -9223372036854775808 > 127.0.0.2 rack1 Up Normal 124.06 KB 20.00% > -5534023222112865485 > 127.0.0.3 rack1 Down Moving 108.7 KB40.00% > 1844674407370955160 > 127.0.0.4 rack1 Up Normal 142.58 KB 0.00% > 1844674407370955161 > 127.0.0.5 rack1 Up Normal 118.64 KB 20.00% > 5534023222112865484 > Node 3 was moving to -1844674407370955160. I added logging to print the > pending and natural endpoints. For ranges owned by node 3, node 3 appeared in > pending and natural endpoints. The blockFor is increased to 3 so we’re > effectively doing CL.ALL operations. This manifests as write timeouts and CAS > unavailables when the node is down. > The correct pending range for this scenario is node 1 is gaining the range > (-1844674407370955160, 1844674407370955160). So node 1 should be added as a > destination for writes and CAS for this range, not node 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10887) Pending range calculator gives wrong pending ranges for moves
[ https://issues.apache.org/jira/browse/CASSANDRA-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074173#comment-15074173 ] sankalp kohli commented on CASSANDRA-10887: --- Will add tests for rack during first week of Jan. > Pending range calculator gives wrong pending ranges for moves > - > > Key: CASSANDRA-10887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10887 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Richard Low >Assignee: sankalp kohli >Priority: Critical > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > Attachments: CASSANDRA-10887.diff, CASSANDRA_10887_v2.diff > > > My understanding is the PendingRangeCalculator is meant to calculate who > should receive extra writes during range movements. However, it adds the > wrong ranges for moves. An extreme example of this can be seen in the > following reproduction. Create a 5 node cluster (I did this on 2.0.16 and > 2.2.4) and a keyspace RF=3 and a simple table. Then start moving a node and > immediately kill -9 it. Now you see a node as down and moving in the ring. > Try a quorum write for a partition that is stored on that node - it will fail > with a timeout. Further, all CAS reads or writes fail immediately with > unavailable exception because they attempt to include the moving node twice. > This is likely to be the cause of CASSANDRA-10423. > In my example I had this ring: > 127.0.0.1 rack1 Up Normal 170.97 KB 20.00% > -9223372036854775808 > 127.0.0.2 rack1 Up Normal 124.06 KB 20.00% > -5534023222112865485 > 127.0.0.3 rack1 Down Moving 108.7 KB40.00% > 1844674407370955160 > 127.0.0.4 rack1 Up Normal 142.58 KB 0.00% > 1844674407370955161 > 127.0.0.5 rack1 Up Normal 118.64 KB 20.00% > 5534023222112865484 > Node 3 was moving to -1844674407370955160. I added logging to print the > pending and natural endpoints. For ranges owned by node 3, node 3 appeared in > pending and natural endpoints. The blockFor is increased to 3 so we’re > effectively doing CL.ALL operations. This manifests as write timeouts and CAS > unavailables when the node is down. > The correct pending range for this scenario is node 1 is gaining the range > (-1844674407370955160, 1844674407370955160). So node 1 should be added as a > destination for writes and CAS for this range, not node 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-10733:
Attachment: 10733-fix-space-2.2.txt
Thanks for the patch! Sorry for the slow response, I had some higher priority
things to take care of before the holidays.
Your attached patch to fix the first issue looks good to me. However, I think
your suggested approach for fixing the trailing space after a partial
autocomplete is not correct. The root of the problem seems to be that after a
partial completion, it's recursively looking for further completions, when we
know that this isn't necessary. I've attached a patch that avoids recursion in
this case.
Would you mind adding some test cases for both of these in
{{pylib/cqlshlib/test/test_cqlsh_completion.py}}?
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt,
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10931) CassandraVersion complains about 3.x version strings
[
https://issues.apache.org/jira/browse/CASSANDRA-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita reassigned CASSANDRA-10931:
--
Assignee: Yuki Morishita
> CassandraVersion complains about 3.x version strings
>
>
> Key: CASSANDRA-10931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10931
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Yuki Morishita
>
> The utest {{SystemKeyspaceTest.snapshotSystemKeyspaceIfUpgrading}} fails with
> {{java.lang.IllegalArgumentException: Invalid version value: 3.2}} (e.g.
> [here|http://cassci.datastax.com/view/trunk/job/trunk_testall/629/testReport/org.apache.cassandra.db/SystemKeyspaceTest/snapshotSystemKeyspaceIfUpgrading/]).
> The question is just:
> # change the regex pattern in {{CassandraVersion}} and silently assume {{.0}}
> as the patch version or
> # go with {{x.y.0}} version strings instead of {{x.y}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10931) CassandraVersion complains about 3.x version strings
[
https://issues.apache.org/jira/browse/CASSANDRA-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-10931:
---
Component/s: Testing
> CassandraVersion complains about 3.x version strings
>
>
> Key: CASSANDRA-10931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10931
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Stupp
>Assignee: Yuki Morishita
> Fix For: 3.x
>
>
> The utest {{SystemKeyspaceTest.snapshotSystemKeyspaceIfUpgrading}} fails with
> {{java.lang.IllegalArgumentException: Invalid version value: 3.2}} (e.g.
> [here|http://cassci.datastax.com/view/trunk/job/trunk_testall/629/testReport/org.apache.cassandra.db/SystemKeyspaceTest/snapshotSystemKeyspaceIfUpgrading/]).
> The question is just:
> # change the regex pattern in {{CassandraVersion}} and silently assume {{.0}}
> as the patch version or
> # go with {{x.y.0}} version strings instead of {{x.y}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10931) CassandraVersion complains about 3.x version strings
[
https://issues.apache.org/jira/browse/CASSANDRA-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074207#comment-15074207
]
Yuki Morishita commented on CASSANDRA-10931:
||branch||testall||dtest||
|[10931|https://github.com/yukim/cassandra/tree/10931]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10931-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10931-dtest/lastCompletedBuild/testReport/]|
I took route 1 above, {{CassandraVersion}} now accepts {{x.y}} as {{x.y.0}}.
> CassandraVersion complains about 3.x version strings
>
>
> Key: CASSANDRA-10931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10931
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Stupp
>Assignee: Yuki Morishita
> Fix For: 3.x
>
>
> The utest {{SystemKeyspaceTest.snapshotSystemKeyspaceIfUpgrading}} fails with
> {{java.lang.IllegalArgumentException: Invalid version value: 3.2}} (e.g.
> [here|http://cassci.datastax.com/view/trunk/job/trunk_testall/629/testReport/org.apache.cassandra.db/SystemKeyspaceTest/snapshotSystemKeyspaceIfUpgrading/]).
> The question is just:
> # change the regex pattern in {{CassandraVersion}} and silently assume {{.0}}
> as the patch version or
> # go with {{x.y.0}} version strings instead of {{x.y}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10949) SSTableMultiWriter streaming bug
[ https://issues.apache.org/jira/browse/CASSANDRA-10949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074212#comment-15074212 ] Yuki Morishita commented on CASSANDRA-10949: +1 > SSTableMultiWriter streaming bug > > > Key: CASSANDRA-10949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10949 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > SSTableMultiWriter can create several sstables, if we do create more than one > during streaming, the streaming operation will hang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10140) Enable GC logging by default
[ https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074219#comment-15074219 ] Ariel Weisberg commented on CASSANDRA-10140: |[2.2 code|https://github.com/apache/cassandra/compare/cassandra-2.2...aweisberg:CASSANDRA-10140-2.2?expand=1]|[utests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10140-2.2-testall/]|[dtests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10140-2.2-dtest/]| |[3.0 code|https://github.com/apache/cassandra/compare/cassandra-3.0...aweisberg:CASSANDRA-10140-3.0?expand=1]|[utests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10140-3.0-testall/]|[dtests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10140-3.0-dtest/]| |[trunk code|https://github.com/apache/cassandra/compare/trunk...aweisberg:CASSANDRA-10140-trunk?expand=1]|[utests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10140-trunk-testall/]|[dtests|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10140-trunk-dtest/]| > Enable GC logging by default > > > Key: CASSANDRA-10140 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10140 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Fix For: 2.2.x, 3.0.x > > Attachments: 10140-debian-packaging-2.2.txt, > 10140-debian-packaging-3.0.txt, CASSANDRA-10140-2-2.txt, > CASSANDRA-10140-v2.txt, CASSANDRA-10140-v3.txt, CASSANDRA-10140.txt, > cassandra-2.2-10140-v2.txt, cassandra-2.2-10140-v3.txt, > casssandra-2.2-10140-v4.txt > > > Overhead for the gc logging is very small (with cycling logs in 7+) and it > provides a ton of useful information. This will open up more for C* > diagnostic tools to provide feedback as well without requiring restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10736) TestTopology.simple_decommission_test failing due to assertion triggered by SizeEstimatesRecorder
[
https://issues.apache.org/jira/browse/CASSANDRA-10736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Knighton reassigned CASSANDRA-10736:
-
Assignee: Joel Knighton
> TestTopology.simple_decommission_test failing due to assertion triggered by
> SizeEstimatesRecorder
> -
>
> Key: CASSANDRA-10736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10736
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Minor
>
> Example
> [here|http://cassci.datastax.com/job/cassandra-2.2_dtest/369/testReport/junit/topology_test/TestTopology/simple_decommission_test/].
> {{SizeEstimatesRecorder}} can race with decommission when it tries to get the
> primary ranges for a node.
> This is because {{getPredecessor}} in {{TokenMetadata}} hits an assertion if
> the token is no longer in {{TokenMetadata}}.
> This no longer occurs in 3.0 because this assertion has been removed and
> replace with different data.
> In both cases, the relationship between the set of tokens in
> {{getPrimaryRangesFor}} (passed in as an argument) and the set of tokens used
> in calls by {{getPredecessor}} (the system ones) should be investigated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10952) NullPointerException in Gossiper.getHostId
Dikang Gu created CASSANDRA-10952: - Summary: NullPointerException in Gossiper.getHostId Key: CASSANDRA-10952 URL: https://issues.apache.org/jira/browse/CASSANDRA-10952 Project: Cassandra Issue Type: Bug Reporter: Dikang Gu We added some nodes into our cluster, for some of them, when they finish bootstrap, they are not shown in the `nodetool status` of other nodes. I checked the logs and found this: 2015-12-29_05:06:23.89461 ERROR 05:06:23 Exception in thread Thread[GossipStage:9,5,main] 2015-12-29_05:06:23.89463 java.lang.NullPointerException: null 2015-12-29_05:06:23.89463 at org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:811) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89464 at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1664) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89464 at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1485) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89464 at org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1156) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89465 at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1138) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89465 at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1095) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89466 at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89466 at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) ~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16] 2015-12-29_05:06:23.89469 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_45] 2015-12-29_05:06:23.89469 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_45] 2015-12-29_05:06:23.89469 at java.lang.Thread.run(Thread.java:744) ~[na:1.7.0_45] This looks different than CASSANDRA-10089, so I create a new jira. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10952) NullPointerException in Gossiper.getHostId
[
https://issues.apache.org/jira/browse/CASSANDRA-10952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-10952:
--
Description:
We added some nodes into our cluster, for some of them, when they finish
bootstrap, they are not shown in the `nodetool status` of other nodes.
I checked the logs and found this:
{code}
2015-12-29_05:06:23.89461 ERROR 05:06:23 Exception in thread
Thread[GossipStage:9,5,main]
2015-12-29_05:06:23.89463 java.lang.NullPointerException: null
2015-12-29_05:06:23.89463 at
org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:811)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89464 at
org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1664)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89464 at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1485)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89464 at
org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1156)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89465 at
org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1138)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89465 at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1095)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89466 at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89466 at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89469 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_45]
2015-12-29_05:06:23.89469 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_45]
2015-12-29_05:06:23.89469 at java.lang.Thread.run(Thread.java:744)
~[na:1.7.0_45]
{code}
This looks different than CASSANDRA-10089, so I create a new jira.
was:
We added some nodes into our cluster, for some of them, when they finish
bootstrap, they are not shown in the `nodetool status` of other nodes.
I checked the logs and found this:
2015-12-29_05:06:23.89461 ERROR 05:06:23 Exception in thread
Thread[GossipStage:9,5,main]
2015-12-29_05:06:23.89463 java.lang.NullPointerException: null
2015-12-29_05:06:23.89463 at
org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:811)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89464 at
org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1664)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89464 at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1485)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89464 at
org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1156)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89465 at
org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1138)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89465 at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1095)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89466 at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89466 at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
~[apache-cassandra-2.1.8+git20151215.c8ed2ab16.jar:2.1.8+git20151215.c8ed2ab16]
2015-12-29_05:06:23.89469 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_45]
2015-12-29_05:06:23.89469 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_45]
2015-12-29_05:06:23.89469 at java.lang.Thread.run(Thread.java:744)
~[na:1.7.0_45]
This looks different than CASSANDRA-10089, so I create a new jira.
> NullPointerException in Gossiper.getHostId
> --
>
> Key: CASSANDRA-1
[jira] [Commented] (CASSANDRA-9464) test-clientutil-jar broken
[
https://issues.apache.org/jira/browse/CASSANDRA-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074318#comment-15074318
]
Matthias Eichstaedt commented on CASSANDRA-9464:
I was not able to reproduce this test failure. Do you still see this issue?
Ran test-clientutil-jar on the cassandra-2.2 branch and did not see any errors.
Same for the branches cassandra-3.0 and cassandra-3.1.
> /usr/lib/jvm/java-8-oracle/bin/java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> test-clientutil-jar broken
> --
>
> Key: CASSANDRA-9464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9464
> Project: Cassandra
> Issue Type: Test
>Reporter: Michael Shuler
> Labels: test-failure
> Fix For: 2.2.x, 3.x
>
>
> {noformat}
> 20:37:37 test-clientutil-jar:
> 20:37:37 [junit] Testsuite: org.apache.cassandra.serializers.ClientUtilsTest
> 20:37:37 [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed: 0.032 sec
> 20:37:37 [junit]
> 20:37:37 [junit] Testcase:
> test(org.apache.cassandra.serializers.ClientUtilsTest):Caused an ERROR
> 20:37:37 [junit] org/apache/thrift/TException
> 20:37:37 [junit] java.lang.NoClassDefFoundError: org/apache/thrift/TException
> 20:37:37 [junit] at
> org.apache.cassandra.utils.UUIDGen.makeNode(UUIDGen.java:275)
> 20:37:37 [junit] at
> org.apache.cassandra.utils.UUIDGen.makeClockSeqAndNode(UUIDGen.java:229)
> 20:37:37 [junit] at
> org.apache.cassandra.utils.UUIDGen.(UUIDGen.java:38)
> 20:37:37 [junit] at
> org.apache.cassandra.serializers.ClientUtilsTest.test(ClientUtilsTest.java:56)
> 20:37:37 [junit] Caused by: java.lang.ClassNotFoundException:
> org.apache.thrift.TException
> 20:37:37 [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 20:37:37 [junit]
> 20:37:37 [junit]
> 20:37:37 Target 'pig-test' failed with message 'The following error occurred
> while executing this line:
> 20:37:37 /home/automaton/cassandra/build.xml:1167: Some pig test(s) failed.'.
> 20:37:37 [junit] Test org.apache.cassandra.serializers.ClientUtilsTest FAILED
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9258) Range movement causes CPU & performance impact
[
https://issues.apache.org/jira/browse/CASSANDRA-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-9258:
-
Attachment: (was: 0001-pending-ranges-maps-for-2.2.patch)
> Range movement causes CPU & performance impact
> --
>
> Key: CASSANDRA-9258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9258
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.1.4
>Reporter: Rick Branson
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: 0001-pending-ranges-map.patch, Screenshot 2015-12-16
> 16.11.36.png, Screenshot 2015-12-16 16.11.51.png
>
>
> Observing big CPU & latency regressions when doing range movements on
> clusters with many tens of thousands of vnodes. See CPU usage increase by
> ~80% when a single node is being replaced.
> Top methods are:
> 1) Ljava/math/BigInteger;.compareTo in
> Lorg/apache/cassandra/dht/ComparableObjectToken;.compareTo
> 2) Lcom/google/common/collect/AbstractMapBasedMultimap;.wrapCollection in
> Lcom/google/common/collect/AbstractMapBasedMultimap$AsMap$AsMapIterator;.next
> 3) Lorg/apache/cassandra/db/DecoratedKey;.compareTo in
> Lorg/apache/cassandra/dht/Range;.contains
> Here's a sample stack from a thread dump:
> {code}
> "Thrift:50673" daemon prio=10 tid=0x7f2f20164800 nid=0x3a04af runnable
> [0x7f2d878d]
>java.lang.Thread.State: RUNNABLE
> at org.apache.cassandra.dht.Range.isWrapAround(Range.java:260)
> at org.apache.cassandra.dht.Range.contains(Range.java:51)
> at org.apache.cassandra.dht.Range.contains(Range.java:110)
> at
> org.apache.cassandra.locator.TokenMetadata.pendingEndpointsFor(TokenMetadata.java:916)
> at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:775)
> at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:541)
> at
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:616)
> at
> org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1101)
> at
> org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1083)
> at
> org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:976)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3996)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3980)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:205)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9258) Range movement causes CPU & performance impact
[
https://issues.apache.org/jira/browse/CASSANDRA-9258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-9258:
-
Attachment: 0001-pending-ranges-maps-for-2.2.patch
[~blambov], addressed comments.
some banchmark results:
{code}
[java] Benchmark Mode
SamplesScore Error Units
[java] o.a.c.t.m.PendingRangesBench.searchToken avgt
150 200922.008 ± 10654.370 ns/op
[java] o.a.c.t.m.PendingRangesBench.searchTokenForOldPendingRangesavgt
150 1662673.223 ± 35110.983 ns/op
{code}
The new version is 8 times faster than the old one.
> Range movement causes CPU & performance impact
> --
>
> Key: CASSANDRA-9258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9258
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.1.4
>Reporter: Rick Branson
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: 0001-pending-ranges-map.patch,
> 0001-pending-ranges-maps-for-2.2.patch, Screenshot 2015-12-16 16.11.36.png,
> Screenshot 2015-12-16 16.11.51.png
>
>
> Observing big CPU & latency regressions when doing range movements on
> clusters with many tens of thousands of vnodes. See CPU usage increase by
> ~80% when a single node is being replaced.
> Top methods are:
> 1) Ljava/math/BigInteger;.compareTo in
> Lorg/apache/cassandra/dht/ComparableObjectToken;.compareTo
> 2) Lcom/google/common/collect/AbstractMapBasedMultimap;.wrapCollection in
> Lcom/google/common/collect/AbstractMapBasedMultimap$AsMap$AsMapIterator;.next
> 3) Lorg/apache/cassandra/db/DecoratedKey;.compareTo in
> Lorg/apache/cassandra/dht/Range;.contains
> Here's a sample stack from a thread dump:
> {code}
> "Thrift:50673" daemon prio=10 tid=0x7f2f20164800 nid=0x3a04af runnable
> [0x7f2d878d]
>java.lang.Thread.State: RUNNABLE
> at org.apache.cassandra.dht.Range.isWrapAround(Range.java:260)
> at org.apache.cassandra.dht.Range.contains(Range.java:51)
> at org.apache.cassandra.dht.Range.contains(Range.java:110)
> at
> org.apache.cassandra.locator.TokenMetadata.pendingEndpointsFor(TokenMetadata.java:916)
> at
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:775)
> at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:541)
> at
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:616)
> at
> org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1101)
> at
> org.apache.cassandra.thrift.CassandraServer.doInsert(CassandraServer.java:1083)
> at
> org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:976)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3996)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3980)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:205)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10953) Make all timeouts configurable via nodetool and jmx
Sebastian Estevez created CASSANDRA-10953: - Summary: Make all timeouts configurable via nodetool and jmx Key: CASSANDRA-10953 URL: https://issues.apache.org/jira/browse/CASSANDRA-10953 Project: Cassandra Issue Type: Bug Reporter: Sebastian Estevez Specifically I was interested in being able to monitor and set stream_socket_timeout_in_ms from either (or both) nodetool and JMX. Chatting with [~thobbs] and [~jeromatron] we suspect it would also be useful to be able to view and edit other C* timeouts via nodetool and JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10953) Make all timeouts configurable via nodetool and jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-10953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna reassigned CASSANDRA-10953: Assignee: Jeremy Hanna > Make all timeouts configurable via nodetool and jmx > --- > > Key: CASSANDRA-10953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10953 > Project: Cassandra > Issue Type: Bug >Reporter: Sebastian Estevez >Assignee: Jeremy Hanna > > Specifically I was interested in being able to monitor and set > stream_socket_timeout_in_ms from either (or both) nodetool and JMX. > Chatting with [~thobbs] and [~jeromatron] we suspect it would also be useful > to be able to view and edit other C* timeouts via nodetool and JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)
[ https://issues.apache.org/jira/browse/CASSANDRA-8844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074425#comment-15074425 ] DOAN DuyHai commented on CASSANDRA-8844: Agree with [~JoshuaMcKenzie] that we should keep the complexity at minimum in C*. > Change Data Capture (CDC) > - > > Key: CASSANDRA-8844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8844 > Project: Cassandra > Issue Type: New Feature > Components: Coordination, Local Write-Read Paths >Reporter: Tupshin Harper >Assignee: Joshua McKenzie >Priority: Critical > Fix For: 3.x > > > "In databases, change data capture (CDC) is a set of software design patterns > used to determine (and track) the data that has changed so that action can be > taken using the changed data. Also, Change data capture (CDC) is an approach > to data integration that is based on the identification, capture and delivery > of the changes made to enterprise data sources." > -Wikipedia > As Cassandra is increasingly being used as the Source of Record (SoR) for > mission critical data in large enterprises, it is increasingly being called > upon to act as the central hub of traffic and data flow to other systems. In > order to try to address the general need, we (cc [~brianmhess]), propose > implementing a simple data logging mechanism to enable per-table CDC patterns. > h2. The goals: > # Use CQL as the primary ingestion mechanism, in order to leverage its > Consistency Level semantics, and in order to treat it as the single > reliable/durable SoR for the data. > # To provide a mechanism for implementing good and reliable > (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) > continuous semi-realtime feeds of mutations going into a Cassandra cluster. > # To eliminate the developmental and operational burden of users so that they > don't have to do dual writes to other systems. > # For users that are currently doing batch export from a Cassandra system, > give them the opportunity to make that realtime with a minimum of coding. > h2. The mechanism: > We propose a durable logging mechanism that functions similar to a commitlog, > with the following nuances: > - Takes place on every node, not just the coordinator, so RF number of copies > are logged. > - Separate log per table. > - Per-table configuration. Only tables that are specified as CDC_LOG would do > any logging. > - Per DC. We are trying to keep the complexity to a minimum to make this an > easy enhancement, but most likely use cases would prefer to only implement > CDC logging in one (or a subset) of the DCs that are being replicated to > - In the critical path of ConsistencyLevel acknowledgment. Just as with the > commitlog, failure to write to the CDC log should fail that node's write. If > that means the requested consistency level was not met, then clients *should* > experience UnavailableExceptions. > - Be written in a Row-centric manner such that it is easy for consumers to > reconstitute rows atomically. > - Written in a simple format designed to be consumed *directly* by daemons > written in non JVM languages > h2. Nice-to-haves > I strongly suspect that the following features will be asked for, but I also > believe that they can be deferred for a subsequent release, and to guage > actual interest. > - Multiple logs per table. This would make it easy to have multiple > "subscribers" to a single table's changes. A workaround would be to create a > forking daemon listener, but that's not a great answer. > - Log filtering. Being able to apply filters, including UDF-based filters > would make Casandra a much more versatile feeder into other systems, and > again, reduce complexity that would otherwise need to be built into the > daemons. > h2. Format and Consumption > - Cassandra would only write to the CDC log, and never delete from it. > - Cleaning up consumed logfiles would be the client daemon's responibility > - Logfile size should probably be configurable. > - Logfiles should be named with a predictable naming schema, making it > triivial to process them in order. > - Daemons should be able to checkpoint their work, and resume from where they > left off. This means they would have to leave some file artifact in the CDC > log's directory. > - A sophisticated daemon should be able to be written that could > -- Catch up, in written-order, even when it is multiple logfiles behind in > processing > -- Be able to continuously "tail" the most recent logfile and get > low-latency(ms?) access to the data as it is written. > h2. Alternate approach > In order to make consuming a change log easy and efficient to do with low > latency, the following could supplement the approach outlined above > - Instead of writing to a logf
[jira] [Resolved] (CASSANDRA-9464) test-clientutil-jar broken
[
https://issues.apache.org/jira/browse/CASSANDRA-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-9464.
---
Resolution: Fixed
Thanks for checking! Confirmed this passes on {{cassandra-2.2}},
{{cassandra-3.0}}, {{cassandra-3.1}}, and {{trunk}} branches, now.
Thanks to whomever fixed this test along the way :-)
{noformat}
test-clientutil-jar:
[junit] Testsuite: org.apache.cassandra.serializers.ClientUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.252 sec
[junit]
BUILD SUCCESSFUL
{noformat}
> test-clientutil-jar broken
> --
>
> Key: CASSANDRA-9464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9464
> Project: Cassandra
> Issue Type: Test
>Reporter: Michael Shuler
> Labels: test-failure
> Fix For: 2.2.x, 3.x
>
>
> {noformat}
> 20:37:37 test-clientutil-jar:
> 20:37:37 [junit] Testsuite: org.apache.cassandra.serializers.ClientUtilsTest
> 20:37:37 [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed: 0.032 sec
> 20:37:37 [junit]
> 20:37:37 [junit] Testcase:
> test(org.apache.cassandra.serializers.ClientUtilsTest):Caused an ERROR
> 20:37:37 [junit] org/apache/thrift/TException
> 20:37:37 [junit] java.lang.NoClassDefFoundError: org/apache/thrift/TException
> 20:37:37 [junit] at
> org.apache.cassandra.utils.UUIDGen.makeNode(UUIDGen.java:275)
> 20:37:37 [junit] at
> org.apache.cassandra.utils.UUIDGen.makeClockSeqAndNode(UUIDGen.java:229)
> 20:37:37 [junit] at
> org.apache.cassandra.utils.UUIDGen.(UUIDGen.java:38)
> 20:37:37 [junit] at
> org.apache.cassandra.serializers.ClientUtilsTest.test(ClientUtilsTest.java:56)
> 20:37:37 [junit] Caused by: java.lang.ClassNotFoundException:
> org.apache.thrift.TException
> 20:37:37 [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 20:37:37 [junit]
> 20:37:37 [junit]
> 20:37:37 Target 'pig-test' failed with message 'The following error occurred
> while executing this line:
> 20:37:37 /home/automaton/cassandra/build.xml:1167: Some pig test(s) failed.'.
> 20:37:37 [junit] Test org.apache.cassandra.serializers.ClientUtilsTest FAILED
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8708) inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited
[ https://issues.apache.org/jira/browse/CASSANDRA-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-8708: Labels: docs-impacting (was: ) > inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited > - > > Key: CASSANDRA-8708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8708 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Adam Hattrell >Assignee: Jeremy Hanna > Labels: docs-impacting > Fix For: 2.1.x, 2.2.x > > Attachments: 8708-2.1-jmx-nodetool-bulkloader-v2.txt, > 8708-2.1-jmx-nodetool-bulkloader.txt, 8708-2.1-with-jmx-nodetool.txt, > 8708-2.1.txt > > > inter_dc_stream_throughput_outbound_megabits_per_sec was introduced in > CASSANDRA-6596. > There's some discussion in the ticket of the intention to link the default to > whatever stream_throughput_outbound_megabits_per_sec is set to. > However, it looks like it's just set to 0 - from > /src/java/org/apache/cassandra/config/Config.java > This is a bit of a pain - usually folks want to set the inter dc limits lower > than the base streaming figure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10953) Make all timeouts configurable via nodetool and jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-10953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-10953: - Labels: docs-impacting (was: ) > Make all timeouts configurable via nodetool and jmx > --- > > Key: CASSANDRA-10953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10953 > Project: Cassandra > Issue Type: Bug >Reporter: Sebastian Estevez >Assignee: Jeremy Hanna > Labels: docs-impacting > > Specifically I was interested in being able to monitor and set > stream_socket_timeout_in_ms from either (or both) nodetool and JMX. > Chatting with [~thobbs] and [~jeromatron] we suspect it would also be useful > to be able to view and edit other C* timeouts via nodetool and JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10931) CassandraVersion complains about 3.x version strings
[
https://issues.apache.org/jira/browse/CASSANDRA-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074492#comment-15074492
]
Yuki Morishita commented on CASSANDRA-10931:
Updated branch for failing tests.
> CassandraVersion complains about 3.x version strings
>
>
> Key: CASSANDRA-10931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10931
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Stupp
>Assignee: Yuki Morishita
> Fix For: 3.x
>
>
> The utest {{SystemKeyspaceTest.snapshotSystemKeyspaceIfUpgrading}} fails with
> {{java.lang.IllegalArgumentException: Invalid version value: 3.2}} (e.g.
> [here|http://cassci.datastax.com/view/trunk/job/trunk_testall/629/testReport/org.apache.cassandra.db/SystemKeyspaceTest/snapshotSystemKeyspaceIfUpgrading/]).
> The question is just:
> # change the regex pattern in {{CassandraVersion}} and silently assume {{.0}}
> as the patch version or
> # go with {{x.y.0}} version strings instead of {{x.y}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8708) inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited
[ https://issues.apache.org/jira/browse/CASSANDRA-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-8708: Attachment: 8708-2.2.txt Added a patch for 2.2, will kick off a cassci test. > inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited > - > > Key: CASSANDRA-8708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8708 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Adam Hattrell >Assignee: Jeremy Hanna > Labels: docs-impacting > Fix For: 2.1.x, 2.2.x > > Attachments: 8708-2.1-jmx-nodetool-bulkloader-v2.txt, > 8708-2.1-jmx-nodetool-bulkloader.txt, 8708-2.1-with-jmx-nodetool.txt, > 8708-2.1.txt, 8708-2.2.txt > > > inter_dc_stream_throughput_outbound_megabits_per_sec was introduced in > CASSANDRA-6596. > There's some discussion in the ticket of the intention to link the default to > whatever stream_throughput_outbound_megabits_per_sec is set to. > However, it looks like it's just set to 0 - from > /src/java/org/apache/cassandra/config/Config.java > This is a bit of a pain - usually folks want to set the inter dc limits lower > than the base streaming figure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8708) inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited
[ https://issues.apache.org/jira/browse/CASSANDRA-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074589#comment-15074589 ] Jeremy Hanna commented on CASSANDRA-8708: - There were some unrelated failures. Can you try locally? > inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited > - > > Key: CASSANDRA-8708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8708 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Adam Hattrell >Assignee: Jeremy Hanna > Labels: docs-impacting > Fix For: 2.1.x, 2.2.x > > Attachments: 8708-2.1-jmx-nodetool-bulkloader-v2.txt, > 8708-2.1-jmx-nodetool-bulkloader.txt, 8708-2.1-with-jmx-nodetool.txt, > 8708-2.1.txt, 8708-2.2.txt > > > inter_dc_stream_throughput_outbound_megabits_per_sec was introduced in > CASSANDRA-6596. > There's some discussion in the ticket of the intention to link the default to > whatever stream_throughput_outbound_megabits_per_sec is set to. > However, it looks like it's just set to 0 - from > /src/java/org/apache/cassandra/config/Config.java > This is a bit of a pain - usually folks want to set the inter dc limits lower > than the base streaming figure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8708) inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited
[ https://issues.apache.org/jira/browse/CASSANDRA-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074589#comment-15074589 ] Jeremy Hanna edited comment on CASSANDRA-8708 at 12/30/15 3:42 AM: --- [~aweisberg]: there were some unrelated failures. Can you try locally? was (Author: jeromatron): There were some unrelated failures. Can you try locally? > inter_dc_stream_throughput_outbound_megabits_per_sec to defaults to unlimited > - > > Key: CASSANDRA-8708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8708 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Adam Hattrell >Assignee: Jeremy Hanna > Labels: docs-impacting > Fix For: 2.1.x, 2.2.x > > Attachments: 8708-2.1-jmx-nodetool-bulkloader-v2.txt, > 8708-2.1-jmx-nodetool-bulkloader.txt, 8708-2.1-with-jmx-nodetool.txt, > 8708-2.1.txt, 8708-2.2.txt > > > inter_dc_stream_throughput_outbound_megabits_per_sec was introduced in > CASSANDRA-6596. > There's some discussion in the ticket of the intention to link the default to > whatever stream_throughput_outbound_megabits_per_sec is set to. > However, it looks like it's just set to 0 - from > /src/java/org/apache/cassandra/config/Config.java > This is a bit of a pain - usually folks want to set the inter dc limits lower > than the base streaming figure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
