[jira] [Commented] (CASSANDRA-7705) Safer Resource Management
[ https://issues.apache.org/jira/browse/CASSANDRA-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236546#comment-14236546 ] Ariel Weisberg commented on CASSANDRA-7705: --- GCC? In Java you can't remove fields from a class conditionally. If you don't want dependencies you can write a simple preprocessor in Java. > Safer Resource Management > - > > Key: CASSANDRA-7705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7705 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict > Fix For: 3.0 > > > We've had a spate of bugs recently with bad reference counting. these can > have potentially dire consequences, generally either randomly deleting data > or giving us infinite loops. > Since in 2.1 we only reference count resources that are relatively expensive > and infrequently managed (or in places where this safety is probably not as > necessary, e.g. SerializingCache), we could without any negative consequences > (and only slight code complexity) introduce a safer resource management > scheme for these more expensive/infrequent actions. > Basically, I propose when we want to acquire a resource we allocate an object > that manages the reference. This can only be released once; if it is released > twice, we fail immediately at the second release, reporting where the bug is > (rather than letting it continue fine until the next correct release corrupts > the count). The reference counter remains the same, but we obtain guarantees > that the reference count itself is never badly maintained, although code > using it could mistakenly release its own handle early (typically this is > only an issue when cleaning up after a failure, in which case under the new > scheme this would be an innocuous error) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8400) nodetool cfstats is missing "Number of Keys (estimate)"
[ https://issues.apache.org/jira/browse/CASSANDRA-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236547#comment-14236547 ] Jonathan Ellis commented on CASSANDRA-8400: --- What commit was this removed in? Was it an oversight or did we decide that an estimate based on STCS was more dangerous than useful? > nodetool cfstats is missing "Number of Keys (estimate)" > --- > > Key: CASSANDRA-8400 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8400 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: C* 2.1.2 >Reporter: Sebastian Estevez >Assignee: Lyuben Todorov >Priority: Minor > Labels: tools > Fix For: 2.1.3 > > > Expected result: > :~$nodetool version > ReleaseVersion: 2.0.11.83 > :~$ nodetool cfstats system.schema_keyspaces|grep keys > Table: schema_keyspaces > Number of keys (estimate): 384 > Result in C* 2.1: > $ bin/nodetool version > ReleaseVersion: 2.1.2 > $ bin/nodetool cfstats system|grep key > Table: schema_keyspaces -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7705) Safer Resource Management
[ https://issues.apache.org/jira/browse/CASSANDRA-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236532#comment-14236532 ] Jonathan Ellis commented on CASSANDRA-7705: --- What do you use for conditional compilation? > Safer Resource Management > - > > Key: CASSANDRA-7705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7705 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict > Fix For: 3.0 > > > We've had a spate of bugs recently with bad reference counting. these can > have potentially dire consequences, generally either randomly deleting data > or giving us infinite loops. > Since in 2.1 we only reference count resources that are relatively expensive > and infrequently managed (or in places where this safety is probably not as > necessary, e.g. SerializingCache), we could without any negative consequences > (and only slight code complexity) introduce a safer resource management > scheme for these more expensive/infrequent actions. > Basically, I propose when we want to acquire a resource we allocate an object > that manages the reference. This can only be released once; if it is released > twice, we fail immediately at the second release, reporting where the bug is > (rather than letting it continue fine until the next correct release corrupts > the count). The reference counter remains the same, but we obtain guarantees > that the reference count itself is never badly maintained, although code > using it could mistakenly release its own handle early (typically this is > only an issue when cleaning up after a failure, in which case under the new > scheme this would be an innocuous error) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8415) Reduce maxHintsInProgress
[ https://issues.apache.org/jira/browse/CASSANDRA-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-8415. --- Resolution: Fixed Reviewer: Jason Brown (was: Aleksey Yeschenko) committed > Reduce maxHintsInProgress > - > > Key: CASSANDRA-8415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8415 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis > Fix For: 2.1.3 > > Attachments: 8415.txt > > > We have lots of evidence at this point that load shedding isn't kicking in > fast enough to stop people from knocking nodes over. A major contributor is > writing hints for dropped mutations on the coordinator. Reducing > maxHintsInProgress will result in OverloadedException being thrown sooner. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[3/3] cassandra git commit: merge from 2.1
merge from 2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6ff4b5e9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6ff4b5e9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6ff4b5e9 Branch: refs/heads/trunk Commit: 6ff4b5e90a3d5d25b8886686cb2835f6cf4c8604 Parents: e7b0883 773a38f Author: Jonathan Ellis Authored: Sat Dec 6 02:59:21 2014 + Committer: Jonathan Ellis Committed: Sat Dec 6 02:59:21 2014 + -- CHANGES.txt | 1 + src/java/org/apache/cassandra/service/StorageProxy.java | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ff4b5e9/CHANGES.txt -- diff --cc CHANGES.txt index 588f58f,b007f31..516faab --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,44 -1,5 +1,45 @@@ +3.0 + * Fix NPE in SelectStatement with empty IN values (CASSANDRA-8419) + * Refactor SelectStatement, return IN results in natural order instead + of IN value list order (CASSANDRA-7981) + * Support UDTs, tuples, and collections in user-defined + functions (CASSANDRA-7563) + * Fix aggregate fn results on empty selection, result column name, + and cqlsh parsing (CASSANDRA-8229) + * Mark sstables as repaired after full repair (CASSANDRA-7586) + * Extend Descriptor to include a format value and refactor reader/writer apis (CASSANDRA-7443) + * Integrate JMH for microbenchmarks (CASSANDRA-8151) + * Keep sstable levels when bootstrapping (CASSANDRA-7460) + * Add Sigar library and perform basic OS settings check on startup (CASSANDRA-7838) + * Support for aggregation functions (CASSANDRA-4914) + * Remove cassandra-cli (CASSANDRA-7920) + * Accept dollar quoted strings in CQL (CASSANDRA-7769) + * Make assassinate a first class command (CASSANDRA-7935) + * Support IN clause on any clustering column (CASSANDRA-4762) + * Improve compaction logging (CASSANDRA-7818) + * Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917) + * Do anticompaction in groups (CASSANDRA-6851) + * Support pure user-defined functions (CASSANDRA-7395, 7526, 7562, 7740, 7781, 7929, + 7924, 7812, 8063, 7813) + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416) + * Move sstable RandomAccessReader to nio2, which allows using the + FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050) + * Remove CQL2 (CASSANDRA-5918) + * Add Thrift get_multi_slice call (CASSANDRA-6757) + * Optimize fetching multiple cells by name (CASSANDRA-6933) + * Allow compilation in java 8 (CASSANDRA-7028) + * Make incremental repair default (CASSANDRA-7250) + * Enable code coverage thru JaCoCo (CASSANDRA-7226) + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) + * Shorten SSTable path (CASSANDRA-6962) + * Use unsafe mutations for most unit tests (CASSANDRA-6969) + * Fix race condition during calculation of pending ranges (CASSANDRA-7390) + * Fail on very large batch sizes (CASSANDRA-8011) + * Improve concurrency of repair (CASSANDRA-6455, 8208) + + 2.1.3 + * Reduce maxHintsInProgress (CASSANDRA-8415) * BTree updates may call provided update function twice (CASSANDRA-8018) * Release sstable references after anticompaction (CASSANDRA-8386) * Handle abort() in SSTableRewriter properly (CASSANDRA-8320) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6ff4b5e9/src/java/org/apache/cassandra/service/StorageProxy.java --
[1/3] cassandra git commit: Reduce maxHintsInProgress patch by jbellis; reviewed by jasobrown for CASSANDRA-8415
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 358f9f3fa -> 773a38f79
refs/heads/trunk e7b088317 -> 6ff4b5e90
Reduce maxHintsInProgress
patch by jbellis; reviewed by jasobrown for CASSANDRA-8415
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/773a38f7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/773a38f7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/773a38f7
Branch: refs/heads/cassandra-2.1
Commit: 773a38f79c30a0e270c46de7bc6430c835e5e995
Parents: 358f9f3
Author: Jonathan Ellis
Authored: Sat Dec 6 02:57:50 2014 +
Committer: Jonathan Ellis
Committed: Sat Dec 6 02:58:53 2014 +
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/service/StorageProxy.java | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/773a38f7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 145347b..b007f31 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.1.3
+ * Reduce maxHintsInProgress (CASSANDRA-8415)
+ * BTree updates may call provided update function twice (CASSANDRA-8018)
* Release sstable references after anticompaction (CASSANDRA-8386)
* Handle abort() in SSTableRewriter properly (CASSANDRA-8320)
* Fix high size calculations for prepared statements (CASSANDRA-8231)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/773a38f7/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d45e74b..5b413af 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -79,7 +79,7 @@ public class StorageProxy implements StorageProxyMBean
public static final StorageProxy instance = new StorageProxy();
-private static volatile int maxHintsInProgress = 1024 *
FBUtilities.getAvailableProcessors();
+private static volatile int maxHintsInProgress = 128 *
FBUtilities.getAvailableProcessors();
private static final CacheLoader
hintsInProgress = new CacheLoader()
{
public AtomicInteger load(InetAddress inetAddress)
[2/3] cassandra git commit: Reduce maxHintsInProgress patch by jbellis; reviewed by jasobrown for CASSANDRA-8415
Reduce maxHintsInProgress
patch by jbellis; reviewed by jasobrown for CASSANDRA-8415
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/773a38f7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/773a38f7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/773a38f7
Branch: refs/heads/trunk
Commit: 773a38f79c30a0e270c46de7bc6430c835e5e995
Parents: 358f9f3
Author: Jonathan Ellis
Authored: Sat Dec 6 02:57:50 2014 +
Committer: Jonathan Ellis
Committed: Sat Dec 6 02:58:53 2014 +
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/service/StorageProxy.java | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/773a38f7/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 145347b..b007f31 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.1.3
+ * Reduce maxHintsInProgress (CASSANDRA-8415)
+ * BTree updates may call provided update function twice (CASSANDRA-8018)
* Release sstable references after anticompaction (CASSANDRA-8386)
* Handle abort() in SSTableRewriter properly (CASSANDRA-8320)
* Fix high size calculations for prepared statements (CASSANDRA-8231)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/773a38f7/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index d45e74b..5b413af 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -79,7 +79,7 @@ public class StorageProxy implements StorageProxyMBean
public static final StorageProxy instance = new StorageProxy();
-private static volatile int maxHintsInProgress = 1024 *
FBUtilities.getAvailableProcessors();
+private static volatile int maxHintsInProgress = 128 *
FBUtilities.getAvailableProcessors();
private static final CacheLoader
hintsInProgress = new CacheLoader()
{
public AtomicInteger load(InetAddress inetAddress)
[jira] [Commented] (CASSANDRA-8414) Avoid loops over array backed iterators that call iter.remove()
[ https://issues.apache.org/jira/browse/CASSANDRA-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236527#comment-14236527 ] Jonathan Ellis commented on CASSANDRA-8414: --- /cc [~slebresne] > Avoid loops over array backed iterators that call iter.remove() > --- > > Key: CASSANDRA-8414 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8414 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Richard Low > Labels: performance > Fix For: 2.1.3 > > > I noticed from sampling that sometimes compaction spends almost all of its > time in iter.remove() in ColumnFamilyStore.removeDeletedStandard. It turns > out that the cf object is using ArrayBackedSortedColumns, so deletes are from > an ArrayList. If the majority of your columns are GCable tombstones then this > is O(n^2). The data structure should be changed or a copy made to avoid this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7882) Memtable slab allocation should scale logarithmically to improve occupancy rate
[ https://issues.apache.org/jira/browse/CASSANDRA-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236526#comment-14236526 ] Jonathan Ellis commented on CASSANDRA-7882: --- Since this only affects NativeAllocator, which is kind of experimental in 2.1 anyway, I'm okay with committing for 2.1.3. > Memtable slab allocation should scale logarithmically to improve occupancy > rate > --- > > Key: CASSANDRA-7882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7882 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jay Patel >Assignee: Benedict > Labels: performance > Fix For: 2.1.3 > > Attachments: trunk-7882.txt > > > CASSANDRA-5935 allows option to disable region-based allocation for on-heap > memtables but there is no option to disable it for off-heap memtables > (memtable_allocation_type: offheap_objects). > Disabling region-based allocation will allow us to pack more tables in the > schema since minimum of 1MB region won't be allocated per table. Downside can > be more fragmentation which should be controllable by using better allocator > like JEMalloc. > How about below option in yaml?: > memtable_allocation_type: unslabbed_offheap_objects > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8413) Bloom filter false positive ratio is not honoured
[ https://issues.apache.org/jira/browse/CASSANDRA-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-8413: - Assignee: Jonathan Ellis > Bloom filter false positive ratio is not honoured > - > > Key: CASSANDRA-8413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8413 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict >Assignee: Jonathan Ellis > Fix For: 2.0.12, 2.1.3 > > Attachments: 8413.hack.txt > > > Whilst thinking about CASSANDRA-7438 and hash bits, I realised we have a > problem with sabotaging our bloom filters when using the murmur3 partitioner. > I have performed a very quick test to confirm this risk is real. > Since a typical cluster uses the same murmur3 hash for partitioning as we do > for bloom filter lookups, and we own a contiguous range, we can guarantee > that the top X bits collide for all keys on the node. This translates into > poor bloom filter distribution. I quickly hacked LongBloomFilterTest to > simulate the problem, and the result in these tests is _up to_ a doubling of > the actual false positive ratio. The actual change will depend on the key > distribution, the number of keys, the false positive ratio, the number of > nodes, the token distribution, etc. But seems to be a real problem for > non-vnode clusters of at least ~128 nodes in size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8413) Bloom filter false positive ratio is not honoured
[ https://issues.apache.org/jira/browse/CASSANDRA-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8413: -- Assignee: Aleksey Yeschenko (was: Jonathan Ellis) > Bloom filter false positive ratio is not honoured > - > > Key: CASSANDRA-8413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8413 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict >Assignee: Aleksey Yeschenko > Fix For: 2.0.12, 2.1.3 > > Attachments: 8413.hack.txt > > > Whilst thinking about CASSANDRA-7438 and hash bits, I realised we have a > problem with sabotaging our bloom filters when using the murmur3 partitioner. > I have performed a very quick test to confirm this risk is real. > Since a typical cluster uses the same murmur3 hash for partitioning as we do > for bloom filter lookups, and we own a contiguous range, we can guarantee > that the top X bits collide for all keys on the node. This translates into > poor bloom filter distribution. I quickly hacked LongBloomFilterTest to > simulate the problem, and the result in these tests is _up to_ a doubling of > the actual false positive ratio. The actual change will depend on the key > distribution, the number of keys, the false positive ratio, the number of > nodes, the token distribution, etc. But seems to be a real problem for > non-vnode clusters of at least ~128 nodes in size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: parseDouble for primitives
Repository: cassandra
Updated Branches:
refs/heads/trunk b7082df27 -> e7b088317
parseDouble for primitives
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e7b08831
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e7b08831
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e7b08831
Branch: refs/heads/trunk
Commit: e7b08831743c48e8718e4cd79093f20d6c2f31c5
Parents: b7082df
Author: Dave Brosius
Authored: Fri Dec 5 21:28:28 2014 -0500
Committer: Dave Brosius
Committed: Fri Dec 5 21:28:28 2014 -0500
--
.../org/apache/cassandra/cql3/statements/PropertyDefinitions.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e7b08831/src/java/org/apache/cassandra/cql3/statements/PropertyDefinitions.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/PropertyDefinitions.java
b/src/java/org/apache/cassandra/cql3/statements/PropertyDefinitions.java
index 23cf8e1..793285b 100644
--- a/src/java/org/apache/cassandra/cql3/statements/PropertyDefinitions.java
+++ b/src/java/org/apache/cassandra/cql3/statements/PropertyDefinitions.java
@@ -106,7 +106,7 @@ public class PropertyDefinitions
{
try
{
-return Double.valueOf(value);
+return Double.parseDouble(value);
}
catch (NumberFormatException e)
{
[2/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/358f9f3f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/358f9f3f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/358f9f3f Branch: refs/heads/trunk Commit: 358f9f3faeac155b48fb74dc92b09d303a87c015 Parents: 6e7a223 a910930 Author: Dave Brosius Authored: Fri Dec 5 21:18:50 2014 -0500 Committer: Dave Brosius Committed: Fri Dec 5 21:18:50 2014 -0500 -- src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/358f9f3f/src/java/org/apache/cassandra/db/ColumnFamilyStore.java --
[1/3] cassandra git commit: use parameterized logging
Repository: cassandra
Updated Branches:
refs/heads/trunk d4a8a8175 -> b7082df27
use parameterized logging
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a9109302
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a9109302
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a9109302
Branch: refs/heads/trunk
Commit: a910930272a4a6443e6c5a2969d5add8b76fe752
Parents: ceed3a2
Author: Dave Brosius
Authored: Fri Dec 5 21:16:54 2014 -0500
Committer: Dave Brosius
Committed: Fri Dec 5 21:16:54 2014 -0500
--
src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a9109302/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index b5c6c98..0e7e5f2 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -1855,14 +1855,14 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
if (sstable == null || !sstable.acquireReference())
{
if (logger.isDebugEnabled())
-logger.debug("using snapshot sstable " +
entries.getKey());
+logger.debug("using snapshot sstable {}",
entries.getKey());
sstable = SSTableReader.open(entries.getKey(),
entries.getValue(), metadata, partitioner);
// This is technically not necessary since it's a snapshot
but makes things easier
sstable.acquireReference();
}
else if (logger.isDebugEnabled())
{
-logger.debug("using active sstable " + entries.getKey());
+logger.debug("using active sstable {}", entries.getKey());
}
readers.add(sstable);
}
[3/3] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b7082df2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b7082df2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b7082df2 Branch: refs/heads/trunk Commit: b7082df2751c169d5579546823b330e6721555af Parents: d4a8a81 358f9f3 Author: Dave Brosius Authored: Fri Dec 5 21:19:21 2014 -0500 Committer: Dave Brosius Committed: Fri Dec 5 21:19:21 2014 -0500 -- src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7082df2/src/java/org/apache/cassandra/db/ColumnFamilyStore.java --
[2/2] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/358f9f3f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/358f9f3f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/358f9f3f Branch: refs/heads/cassandra-2.1 Commit: 358f9f3faeac155b48fb74dc92b09d303a87c015 Parents: 6e7a223 a910930 Author: Dave Brosius Authored: Fri Dec 5 21:18:50 2014 -0500 Committer: Dave Brosius Committed: Fri Dec 5 21:18:50 2014 -0500 -- src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/358f9f3f/src/java/org/apache/cassandra/db/ColumnFamilyStore.java --
[1/2] cassandra git commit: use parameterized logging
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 6e7a22317 -> 358f9f3fa
use parameterized logging
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a9109302
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a9109302
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a9109302
Branch: refs/heads/cassandra-2.1
Commit: a910930272a4a6443e6c5a2969d5add8b76fe752
Parents: ceed3a2
Author: Dave Brosius
Authored: Fri Dec 5 21:16:54 2014 -0500
Committer: Dave Brosius
Committed: Fri Dec 5 21:16:54 2014 -0500
--
src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a9109302/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index b5c6c98..0e7e5f2 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -1855,14 +1855,14 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
if (sstable == null || !sstable.acquireReference())
{
if (logger.isDebugEnabled())
-logger.debug("using snapshot sstable " +
entries.getKey());
+logger.debug("using snapshot sstable {}",
entries.getKey());
sstable = SSTableReader.open(entries.getKey(),
entries.getValue(), metadata, partitioner);
// This is technically not necessary since it's a snapshot
but makes things easier
sstable.acquireReference();
}
else if (logger.isDebugEnabled())
{
-logger.debug("using active sstable " + entries.getKey());
+logger.debug("using active sstable {}", entries.getKey());
}
readers.add(sstable);
}
cassandra git commit: use parameterized logging
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 ceed3a20e -> a91093027
use parameterized logging
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a9109302
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a9109302
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a9109302
Branch: refs/heads/cassandra-2.0
Commit: a910930272a4a6443e6c5a2969d5add8b76fe752
Parents: ceed3a2
Author: Dave Brosius
Authored: Fri Dec 5 21:16:54 2014 -0500
Committer: Dave Brosius
Committed: Fri Dec 5 21:16:54 2014 -0500
--
src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a9109302/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index b5c6c98..0e7e5f2 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -1855,14 +1855,14 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
if (sstable == null || !sstable.acquireReference())
{
if (logger.isDebugEnabled())
-logger.debug("using snapshot sstable " +
entries.getKey());
+logger.debug("using snapshot sstable {}",
entries.getKey());
sstable = SSTableReader.open(entries.getKey(),
entries.getValue(), metadata, partitioner);
// This is technically not necessary since it's a snapshot
but makes things easier
sstable.acquireReference();
}
else if (logger.isDebugEnabled())
{
-logger.debug("using active sstable " + entries.getKey());
+logger.debug("using active sstable {}", entries.getKey());
}
readers.add(sstable);
}
[jira] [Commented] (CASSANDRA-8409) Node generating a huge number of tiny sstable_activity flushes
[
https://issues.apache.org/jira/browse/CASSANDRA-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236493#comment-14236493
]
Jonathan Ellis commented on CASSANDRA-8409:
---
Anything obvious occur to you [~benedict]?
> Node generating a huge number of tiny sstable_activity flushes
> --
>
> Key: CASSANDRA-8409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8409
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1.0, Oracle JDK 1.8.0_25, Ubuntu 12.04
>Reporter: Fred Wulff
> Fix For: 2.1.3
>
> Attachments: system-sstable_activity-ka-67802-Data.db
>
>
> On one of my nodes, I’m seeing hundreds per second of “INFO 21:28:05
> Enqueuing flush of sstable_activity: 0 (0%) on-heap, 33 (0%) off-heap”.
> tpstats shows a steadily climbing # of pending
> MemtableFlushWriter/MemtablePostFlush until the node OOMs. When the flushes
> actually happen the sstable written is invariably 121 bytes. I’m writing
> pretty aggressively to one of my user tables (sev.mdb_group_pit), but that
> table's flushing behavior seems reasonable.
> tpstats:
> {quote}
> frew@hostname:~/s_dist/apache-cassandra-2.1.0$ bin/nodetool -h hostname
> tpstats
> Pool NameActive Pending Completed Blocked All
> time blocked
> MutationStage 128 4429 36810 0
> 0
> ReadStage 0 0 1205 0
> 0
> RequestResponseStage 0 0 24910 0
> 0
> ReadRepairStage 0 0 26 0
> 0
> CounterMutationStage 0 0 0 0
> 0
> MiscStage 0 0 0 0
> 0
> HintedHandoff 2 2 9 0
> 0
> GossipStage 0 0 5157 0
> 0
> CacheCleanupExecutor 0 0 0 0
> 0
> InternalResponseStage 0 0 0 0
> 0
> CommitLogArchiver 0 0 0 0
> 0
> CompactionExecutor428429 0
> 0
> ValidationExecutor0 0 0 0
> 0
> MigrationStage0 0 0 0
> 0
> AntiEntropyStage 0 0 0 0
> 0
> PendingRangeCalculator0 0 11 0
> 0
> MemtableFlushWriter 8 38644 8987 0
> 0
> MemtablePostFlush 1 38940 8735 0
> 0
> MemtableReclaimMemory 0 0 8987 0
> 0
> Message type Dropped
> READ 0
> RANGE_SLICE 0
> _TRACE 0
> MUTATION 10457
> COUNTER_MUTATION 0
> BINARY 0
> REQUEST_RESPONSE 0
> PAGED_RANGE 0
> READ_REPAIR208
> {quote}
> I've attached one of the produced sstables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8371) DateTieredCompactionStrategy is always compacting
[
https://issues.apache.org/jira/browse/CASSANDRA-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236482#comment-14236482
]
Jonathan Ellis commented on CASSANDRA-8371:
---
bq. Another way of saying that is that once you have satisfactorily addressed
sstable-per-read concerns, any further IO spent on coalescing sstables is
probably wasted
Except that repair will inject new sstables into what you've "satisfactorily
addressed." So you do want max age to be long enough to allow repair first.
bq. Regarding the trade-off between sstable counts and compaction IO, the max
age is one of the primary dials you can turn to affect this.
Is that a bug? ISTM that if the boundary is increasing exponentially as
designed, compaction activity outside the current base window should fall off
quickly.
> DateTieredCompactionStrategy is always compacting
> --
>
> Key: CASSANDRA-8371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8371
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: mck
>Assignee: Björn Hegerfors
> Labels: compaction, performance
> Attachments: java_gc_counts_rate-month.png,
> read-latency-recommenders-adview.png, read-latency.png,
> sstables-recommenders-adviews.png, sstables.png, vg2_iad-month.png
>
>
> Running 2.0.11 and having switched a table to
> [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that
> disk IO and gc count increase, along with the number of reads happening in
> the "compaction" hump of cfhistograms.
> Data, and generally performance, looks good, but compactions are always
> happening, and pending compactions are building up.
> The schema for this is
> {code}CREATE TABLE search (
> loginid text,
> searchid timeuuid,
> description text,
> searchkey text,
> searchurl text,
> PRIMARY KEY ((loginid), searchid)
> );{code}
> We're sitting on about 82G (per replica) across 6 nodes in 4 DCs.
> CQL executed against this keyspace, and traffic patterns, can be seen in
> slides 7+8 of https://prezi.com/b9-aj6p2esft/
> Attached are sstables-per-read and read-latency graphs from cfhistograms, and
> screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44),
> to DTCS (week ~46).
> These screenshots are also found in the prezi on slides 9-11.
> [~pmcfadin], [~Bj0rn],
> Can this be a consequence of occasional deleted rows, as is described under
> (3) in the description of CASSANDRA-6602 ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
cassandra git commit: fix incompatibility between formal and actual format parms
Repository: cassandra
Updated Branches:
refs/heads/trunk d6528a7eb -> d4a8a8175
fix incompatibility between formal and actual format parms
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d4a8a817
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d4a8a817
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d4a8a817
Branch: refs/heads/trunk
Commit: d4a8a81757f1db6c98bffdb56d145a4efd6b7cdf
Parents: d6528a7
Author: Dave Brosius
Authored: Fri Dec 5 21:02:58 2014 -0500
Committer: Dave Brosius
Committed: Fri Dec 5 21:02:58 2014 -0500
--
src/java/org/apache/cassandra/repair/LocalSyncTask.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4a8a817/src/java/org/apache/cassandra/repair/LocalSyncTask.java
--
diff --git a/src/java/org/apache/cassandra/repair/LocalSyncTask.java
b/src/java/org/apache/cassandra/repair/LocalSyncTask.java
index bbb6362..010c959 100644
--- a/src/java/org/apache/cassandra/repair/LocalSyncTask.java
+++ b/src/java/org/apache/cassandra/repair/LocalSyncTask.java
@@ -103,7 +103,7 @@ public class LocalSyncTask extends SyncTask implements
StreamEventHandler
public void onSuccess(StreamState result)
{
-String message = String.format("Sync complete between %s and %s on
%s", desc.sessionId, r1.endpoint, r2.endpoint, desc.columnFamily);
+String message = String.format("Sync complete using session %s between
%s and %s on %s", desc.sessionId, r1.endpoint, r2.endpoint, desc.columnFamily);
logger.info("[repair #{}] {}", desc.sessionId, message);
Tracing.traceRepair(message);
set(stat);
[jira] [Commented] (CASSANDRA-8406) Add option to set max_sstable_age in seconds in DTCS
[ https://issues.apache.org/jira/browse/CASSANDRA-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236478#comment-14236478 ] Jonathan Ellis commented on CASSANDRA-8406: --- I'm still -0 on adding two options for the same functionality. And I still think days is usually the "right" unit to encourage in production. > Add option to set max_sstable_age in seconds in DTCS > > > Key: CASSANDRA-8406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8406 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 2.0.12 > > Attachments: 0001-patch.patch > > > Using days as the unit for max_sstable_age in DTCS might be too much, add > option to set it in seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8397) Support UPDATE with IN requirement for clustering key
[
https://issues.apache.org/jira/browse/CASSANDRA-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236475#comment-14236475
]
Jonathan Ellis commented on CASSANDRA-8397:
---
We've never supported multi-row updates. I'm not sure it's worth special
casing this one.
> Support UPDATE with IN requirement for clustering key
> -
>
> Key: CASSANDRA-8397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8397
> Project: Cassandra
> Issue Type: Wish
>Reporter: Jens Rantil
>Assignee: Benjamin Lerer
>Priority: Minor
>
> {noformat}
> CREATE TABLE events (
> userid uuid,
> id timeuuid,
> content text,
> type text,
> PRIMARY KEY (userid, id)
> )
> # Add data
> cqlsh:mykeyspace> UPDATE events SET content='Hello' WHERE
> userid=57b47f85-56c4-4968-83cf-4c4e533944e9 AND id IN
> (046e9da0-7945-11e4-a76f-770773bbbf7e, 046e0160-7945-11e4-a76f-770773bbbf7e);
> code=2200 [Invalid query] message="Invalid operator IN for PRIMARY KEY part
> id"
> {noformat}
> I was surprised this doesn't work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8433) Add jmx and nodetool controls to reset lifetime metrics to zero
[ https://issues.apache.org/jira/browse/CASSANDRA-8433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Smith updated CASSANDRA-8433: Summary: Add jmx and nodetool controls to reset lifetime metrics to zero (was: Add jmx and mdoetool controls to reset lifetime metrics to zero) > Add jmx and nodetool controls to reset lifetime metrics to zero > --- > > Key: CASSANDRA-8433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8433 > Project: Cassandra > Issue Type: Improvement >Reporter: Donald Smith >Priority: Minor > > Often I change some parameter in cassandra, in the OS, or in an external > component and want to see the effect on cassandra performance. Because some > the jmx metrics are for the lifetime of the process, it's hard to see the > effect of changes. It's inconvenient to restart all the nodes. And if you > restart only some nodes (as I often do) then only those metrics reset to zero. > The jmx interface should provide a way to reset all lifetime metrics to zero. > And *nodetool* should invoke that to allow resetting metrics from the > command line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8267) Only stream from unrepaired sstables during incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-8267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236321#comment-14236321
]
Yuki Morishita commented on CASSANDRA-8267:
---
Since we already send/receive {{repairedAt}} timestamp when doing incremental,
can't we just use that to filter out repaired SSTables?
That way we don't break anything in mid-2.1 release.
> Only stream from unrepaired sstables during incremental repair
> --
>
> Key: CASSANDRA-8267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8267
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
>
> Seems we stream from all sstables even if we do incremental repair, we should
> limit this to only stream from the unrepaired sstables if we do incremental
> repair
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8053) Support for user defined aggregate functions
[
https://issues.apache.org/jira/browse/CASSANDRA-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236305#comment-14236305
]
Robert Stupp commented on CASSANDRA-8053:
-
bq. Giving the point above, I'd rather then just stick to Postgres syntax and
keep it mandatory for now
+1
It's irrelevant for a running C* instance (and for cqlsh DESCRIBE) since the
resolved type is stored in the schema table. But it could mess up creation
scripts that might behave differently against different clusters.
> Support for user defined aggregate functions
>
>
> Key: CASSANDRA-8053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8053
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: cql, udf
> Fix For: 3.0
>
> Attachments: 8053v1.txt
>
>
> CASSANDRA-4914 introduces aggregate functions.
> This ticket is about to decide how we can support "user defined aggregate
> functions". UD aggregate functions should be supported for all UDF flavors
> (class, java, jsr223).
> Things to consider:
> * Special implementations for each scripting language should be omitted
> * No exposure of internal APIs (e.g. {{AggregateFunction}} interface)
> * No need for users to deal with serializers / codecs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5883) Switch to Logback
[ https://issues.apache.org/jira/browse/CASSANDRA-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236101#comment-14236101 ] Michael Shuler commented on CASSANDRA-5883: --- [~rramanan], please open an Improvement JIRA bug report with that info - some before/after performance numbers with some defined workload might be interesting. > Switch to Logback > - > > Key: CASSANDRA-5883 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5883 > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Reporter: Jonathan Ellis >Assignee: Dave Brosius >Priority: Minor > Fix For: 2.1 beta1 > > Attachments: 0001-Additional-migration-to-logback.patch, 5883-1.txt, > 5883-additional1.txt, 5883.txt > > > Logback has a number of advantages over log4j, and switching will be > straightforward since we are already using the slf4j translation layer: > http://logback.qos.ch/reasonsToSwitch.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8400) nodetool cfstats is missing "Number of Keys (estimate)"
[ https://issues.apache.org/jira/browse/CASSANDRA-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236059#comment-14236059 ] Sebastian Estevez commented on CASSANDRA-8400: -- Nice, thanks [~lyubent] > nodetool cfstats is missing "Number of Keys (estimate)" > --- > > Key: CASSANDRA-8400 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8400 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: C* 2.1.2 >Reporter: Sebastian Estevez >Assignee: Lyuben Todorov >Priority: Minor > Labels: tools > Fix For: 2.1.3 > > > Expected result: > :~$nodetool version > ReleaseVersion: 2.0.11.83 > :~$ nodetool cfstats system.schema_keyspaces|grep keys > Table: schema_keyspaces > Number of keys (estimate): 384 > Result in C* 2.1: > $ bin/nodetool version > ReleaseVersion: 2.1.2 > $ bin/nodetool cfstats system|grep key > Table: schema_keyspaces -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8400) nodetool cfstats is missing "Number of Keys (estimate)"
[ https://issues.apache.org/jira/browse/CASSANDRA-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyuben Todorov updated CASSANDRA-8400: -- Priority: Minor (was: Major) > nodetool cfstats is missing "Number of Keys (estimate)" > --- > > Key: CASSANDRA-8400 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8400 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: C* 2.1.2 >Reporter: Sebastian Estevez >Assignee: Lyuben Todorov >Priority: Minor > Labels: tools > Fix For: 2.1.3 > > > Expected result: > :~$nodetool version > ReleaseVersion: 2.0.11.83 > :~$ nodetool cfstats system.schema_keyspaces|grep keys > Table: schema_keyspaces > Number of keys (estimate): 384 > Result in C* 2.1: > $ bin/nodetool version > ReleaseVersion: 2.1.2 > $ bin/nodetool cfstats system|grep key > Table: schema_keyspaces -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Clean up string handling in powershell launch, check for JMX_PORT env var
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 b7a0cd9e6 -> 6e7a22317
Clean up string handling in powershell launch, check for JMX_PORT env var
Patch by jmckenzie; reviewed by pthompson for CASSANDRA-8423
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6e7a2231
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6e7a2231
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6e7a2231
Branch: refs/heads/cassandra-2.1
Commit: 6e7a22317537ba5026b00374af4e50f055e9c4eb
Parents: b7a0cd9
Author: Joshua McKenzie
Authored: Fri Dec 5 14:19:28 2014 -0600
Committer: Joshua McKenzie
Committed: Fri Dec 5 14:19:28 2014 -0600
--
bin/cassandra.ps1 | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6e7a2231/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 3884fa5..80049ee 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -269,6 +269,7 @@ $env:JAVA_BIN
WARNING! Failed to write pidfile to $pidfile. stop-server.bat and
startup protection will not be available.
"@
+echo $_.Exception.Message
exit 1
}
@@ -292,8 +293,8 @@ Function VerifyPortsAreAvailable
$toMatch =
@("storage_port:","ssl_storage_port:","native_transport_port:","rpc_port")
$yaml = Get-Content "$env:CASSANDRA_CONF\cassandra.yaml"
-$listenAddress = "unknown"
-$rpcAddress = "unknown"
+$listenAddress = ""
+$rpcAddress = ""
foreach ($line in $yaml)
{
if ($line -match "^listen_address:")
@@ -307,14 +308,14 @@ Function VerifyPortsAreAvailable
$rpcAddress = $args[1] -replace " ", ""
}
}
-if ($listenAddress -eq "unknown")
+if ([string]::IsNullOrEmpty($listenAddress))
{
-echo "Failed to parse listen_address from cassandra.yaml to check open
ports. Aborting startup."
+Write-Error "Failed to parse listen_address from cassandra.yaml to
check open ports. Aborting startup."
Exit
}
-if ($rpcAddress -eq "unknown")
+if ([string]::IsNullOrEmpty($rpcAddress))
{
-echo "Failed to parse rpc_address from cassandra.yaml to check open
ports. Aborting startup."
+Write-Error "Failed to parse rpc_address from cassandra.yaml to check
open ports. Aborting startup."
Exit
}
@@ -335,6 +336,11 @@ Function VerifyPortsAreAvailable
}
}
}
+if ([string]::IsNullOrEmpty($env:JMX_PORT))
+{
+Write-Error "No JMX_PORT is set in environment. Aborting startup."
+Exit
+}
CheckPort $listenAddress "jmx_port: $env:JMX_PORT"
}
[1/2] cassandra git commit: Clean up string handling in powershell launch, check for JMX_PORT env var
Repository: cassandra
Updated Branches:
refs/heads/trunk 98cf63431 -> d6528a7eb
Clean up string handling in powershell launch, check for JMX_PORT env var
Patch by jmckenzie; reviewed by pthompson for CASSANDRA-8423
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6e7a2231
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6e7a2231
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6e7a2231
Branch: refs/heads/trunk
Commit: 6e7a22317537ba5026b00374af4e50f055e9c4eb
Parents: b7a0cd9
Author: Joshua McKenzie
Authored: Fri Dec 5 14:19:28 2014 -0600
Committer: Joshua McKenzie
Committed: Fri Dec 5 14:19:28 2014 -0600
--
bin/cassandra.ps1 | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6e7a2231/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 3884fa5..80049ee 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -269,6 +269,7 @@ $env:JAVA_BIN
WARNING! Failed to write pidfile to $pidfile. stop-server.bat and
startup protection will not be available.
"@
+echo $_.Exception.Message
exit 1
}
@@ -292,8 +293,8 @@ Function VerifyPortsAreAvailable
$toMatch =
@("storage_port:","ssl_storage_port:","native_transport_port:","rpc_port")
$yaml = Get-Content "$env:CASSANDRA_CONF\cassandra.yaml"
-$listenAddress = "unknown"
-$rpcAddress = "unknown"
+$listenAddress = ""
+$rpcAddress = ""
foreach ($line in $yaml)
{
if ($line -match "^listen_address:")
@@ -307,14 +308,14 @@ Function VerifyPortsAreAvailable
$rpcAddress = $args[1] -replace " ", ""
}
}
-if ($listenAddress -eq "unknown")
+if ([string]::IsNullOrEmpty($listenAddress))
{
-echo "Failed to parse listen_address from cassandra.yaml to check open
ports. Aborting startup."
+Write-Error "Failed to parse listen_address from cassandra.yaml to
check open ports. Aborting startup."
Exit
}
-if ($rpcAddress -eq "unknown")
+if ([string]::IsNullOrEmpty($rpcAddress))
{
-echo "Failed to parse rpc_address from cassandra.yaml to check open
ports. Aborting startup."
+Write-Error "Failed to parse rpc_address from cassandra.yaml to check
open ports. Aborting startup."
Exit
}
@@ -335,6 +336,11 @@ Function VerifyPortsAreAvailable
}
}
}
+if ([string]::IsNullOrEmpty($env:JMX_PORT))
+{
+Write-Error "No JMX_PORT is set in environment. Aborting startup."
+Exit
+}
CheckPort $listenAddress "jmx_port: $env:JMX_PORT"
}
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d6528a7e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d6528a7e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d6528a7e Branch: refs/heads/trunk Commit: d6528a7ebddecb536fac9d8d375a6cd04d052acf Parents: 98cf634 6e7a223 Author: Joshua McKenzie Authored: Fri Dec 5 14:20:43 2014 -0600 Committer: Joshua McKenzie Committed: Fri Dec 5 14:20:43 2014 -0600 -- bin/cassandra.ps1 | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) --
[jira] [Updated] (CASSANDRA-8433) Add jmx and mdoetool controls to reset lifetime metrics to zero
[ https://issues.apache.org/jira/browse/CASSANDRA-8433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Smith updated CASSANDRA-8433: Description: Often I change some parameter in cassandra, in the OS, or in an external component and want to see the effect on cassandra performance. Because some the jmx metrics are for the lifetime of the process, it's hard to see the effect of changes. It's inconvenient to restart all the nodes. And if you restart only some nodes (as I often do) then only those metrics reset to zero. The jmx interface should provide a way to reset all lifetime metrics to zero. And *nodetool* should invoke that to allow resetting metrics from the command line. was: Often I change some parameter in cassandra, in the OS, or in an external component and want to see the effect on cassandra performance. Because some the jmx metrics are for the lifetime of the process, it's hard to see the effect of changes. It's inconvenient to restart all the nodes. And if you restart only some nodes (as I often do) then only those metrics reset to zero. The jmx interface should provide a way to reset all lifetime metrics to zero. > Add jmx and mdoetool controls to reset lifetime metrics to zero > --- > > Key: CASSANDRA-8433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8433 > Project: Cassandra > Issue Type: Improvement >Reporter: Donald Smith >Priority: Minor > > Often I change some parameter in cassandra, in the OS, or in an external > component and want to see the effect on cassandra performance. Because some > the jmx metrics are for the lifetime of the process, it's hard to see the > effect of changes. It's inconvenient to restart all the nodes. And if you > restart only some nodes (as I often do) then only those metrics reset to zero. > The jmx interface should provide a way to reset all lifetime metrics to zero. > And *nodetool* should invoke that to allow resetting metrics from the > command line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8433) Add jmx and mdoetool controls to reset lifetime metrics to zero
[ https://issues.apache.org/jira/browse/CASSANDRA-8433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Smith updated CASSANDRA-8433: Summary: Add jmx and mdoetool controls to reset lifetime metrics to zero (was: Add jmx control to reset lifetime metrics to zero) > Add jmx and mdoetool controls to reset lifetime metrics to zero > --- > > Key: CASSANDRA-8433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8433 > Project: Cassandra > Issue Type: Improvement >Reporter: Donald Smith >Priority: Minor > > Often I change some parameter in cassandra, in the OS, or in an external > component and want to see the effect on cassandra performance. Because some > the jmx metrics are for the lifetime of the process, it's hard to see the > effect of changes. It's inconvenient to restart all the nodes. And if you > restart only some nodes (as I often do) then only those metrics reset to zero. > The jmx interface should provide a way to reset all lifetime metrics to zero. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8423) Error during start up on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-8423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236017#comment-14236017
]
Philip Thompson commented on CASSANDRA-8423:
I've committed the ccm patch. +1 to the powershell changes, the checks for null
or empty are much cleaner now.
> Error during start up on windows
>
>
> Key: CASSANDRA-8423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8423
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
>Priority: Minor
> Labels: windows
> Fix For: 2.1.3
>
> Attachments: 8423_ccm.txt, 8423_powershell.txt
>
>
> While using ccm with the current C* 2.1-HEAD code on Windows, I frequently
> see this exception.
> {code}[node1 ERROR] Exception calling "BeginConnect" with "4" argument(s):
> "The requested address
> is not valid in its context"
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:358
>
> char:9
> + $connect = $tcpobject.BeginConnect($listenAddress, $port, $null,
> $null)
> +
> ~~~
> + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
> + FullyQualifiedErrorId : SocketException
>
> You cannot call a method on a null-valued expression.
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:359
>
> char:9
> + $wait = $connect.AsyncWaitHandle.WaitOne(25, $false)
> +
> + CategoryInfo : InvalidOperation: (:) [], RuntimeException
> + FullyQualifiedErrorId : InvokeMethodOnNull{code}
> I have not yet seen this exception when psutil is not installed, but that may
> not be relevant, as I dont know how that could possibly matter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8423) Error during start up on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-8423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236012#comment-14236012
]
Joshua McKenzie commented on CASSANDRA-8423:
[ccm PR|https://github.com/pcmanus/ccm/pull/218]
> Error during start up on windows
>
>
> Key: CASSANDRA-8423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8423
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
>Priority: Minor
> Labels: windows
> Fix For: 2.1.3
>
> Attachments: 8423_ccm.txt, 8423_powershell.txt
>
>
> While using ccm with the current C* 2.1-HEAD code on Windows, I frequently
> see this exception.
> {code}[node1 ERROR] Exception calling "BeginConnect" with "4" argument(s):
> "The requested address
> is not valid in its context"
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:358
>
> char:9
> + $connect = $tcpobject.BeginConnect($listenAddress, $port, $null,
> $null)
> +
> ~~~
> + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
> + FullyQualifiedErrorId : SocketException
>
> You cannot call a method on a null-valued expression.
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:359
>
> char:9
> + $wait = $connect.AsyncWaitHandle.WaitOne(25, $false)
> +
> + CategoryInfo : InvalidOperation: (:) [], RuntimeException
> + FullyQualifiedErrorId : InvokeMethodOnNull{code}
> I have not yet seen this exception when psutil is not installed, but that may
> not be relevant, as I dont know how that could possibly matter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8423) Error during start up on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-8423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-8423:
---
Reviewer: Philip Thompson
Priority: Minor (was: Major)
> Error during start up on windows
>
>
> Key: CASSANDRA-8423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8423
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
>Priority: Minor
> Labels: windows
> Fix For: 2.1.3
>
> Attachments: 8423_ccm.txt, 8423_powershell.txt
>
>
> While using ccm with the current C* 2.1-HEAD code on Windows, I frequently
> see this exception.
> {code}[node1 ERROR] Exception calling "BeginConnect" with "4" argument(s):
> "The requested address
> is not valid in its context"
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:358
>
> char:9
> + $connect = $tcpobject.BeginConnect($listenAddress, $port, $null,
> $null)
> +
> ~~~
> + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
> + FullyQualifiedErrorId : SocketException
>
> You cannot call a method on a null-valued expression.
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:359
>
> char:9
> + $wait = $connect.AsyncWaitHandle.WaitOne(25, $false)
> +
> + CategoryInfo : InvalidOperation: (:) [], RuntimeException
> + FullyQualifiedErrorId : InvokeMethodOnNull{code}
> I have not yet seen this exception when psutil is not installed, but that may
> not be relevant, as I dont know how that could possibly matter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8423) Error during start up on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-8423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-8423:
---
Attachment: 8423_powershell.txt
8423_ccm.txt
Regex in ccm to grab JMX_PORT was too greedy and was steamrolling the
$env:JMX_PORT= assignment as well as the initial assignment in
conf/cassandra-env.ps1
Attached a patch for ccm to fix this as well as add a print out of
stdout/stderr from a node on the -v flag to cluster start() method so you can
debug startup problems from ccm and get visibility to errors there.
Also attached a patch to make the powershell port checking a little more .NET
idiomatic, print out the exception on failure to start, and also check that the
JMX_PORT entry in the environment is actually set.
> Error during start up on windows
>
>
> Key: CASSANDRA-8423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8423
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.3
>
> Attachments: 8423_ccm.txt, 8423_powershell.txt
>
>
> While using ccm with the current C* 2.1-HEAD code on Windows, I frequently
> see this exception.
> {code}[node1 ERROR] Exception calling "BeginConnect" with "4" argument(s):
> "The requested address
> is not valid in its context"
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:358
>
> char:9
> + $connect = $tcpobject.BeginConnect($listenAddress, $port, $null,
> $null)
> +
> ~~~
> + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
> + FullyQualifiedErrorId : SocketException
>
> You cannot call a method on a null-valued expression.
> At
> D:\jenkins\workspace\cassandra-2.1_dtest_win32\cassandra\bin\cassandra.ps1:359
>
> char:9
> + $wait = $connect.AsyncWaitHandle.WaitOne(25, $false)
> +
> + CategoryInfo : InvalidOperation: (:) [], RuntimeException
> + FullyQualifiedErrorId : InvokeMethodOnNull{code}
> I have not yet seen this exception when psutil is not installed, but that may
> not be relevant, as I dont know how that could possibly matter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7019) Major tombstone compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235992#comment-14235992 ] Jonathan Ellis commented on CASSANDRA-7019: --- That probably fits how compaction thinks of its job, better than trying to do it 1:1. +1 from me. > Major tombstone compaction > -- > > Key: CASSANDRA-7019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7019 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: compaction > Fix For: 3.0 > > > It should be possible to do a "major" tombstone compaction by including all > sstables, but writing them out 1:1, meaning that if you have 10 sstables > before, you will have 10 sstables after the compaction with the same data, > minus all the expired tombstones. > We could do this in two ways: > # a nodetool command that includes _all_ sstables > # once we detect that an sstable has more than x% (20%?) expired tombstones, > we start one of these compactions, and include all overlapping sstables that > contain older data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Fix NPE in SelectStatement with empty IN values
Repository: cassandra
Updated Branches:
refs/heads/trunk 58c88b7d5 -> 98cf63431
Fix NPE in SelectStatement with empty IN values
Patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-8419
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/98cf6343
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/98cf6343
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/98cf6343
Branch: refs/heads/trunk
Commit: 98cf63431af3d1cd6a411e311250ab71961df9e7
Parents: 58c88b7
Author: blerer
Authored: Fri Dec 5 13:15:35 2014 -0600
Committer: Tyler Hobbs
Committed: Fri Dec 5 13:15:35 2014 -0600
--
CHANGES.txt | 1 +
.../SingleColumnPrimaryKeyRestrictions.java | 9 +++--
.../cassandra/cql3/MultiColumnRelationTest.java | 4
.../cassandra/cql3/SingleColumnRelationTest.java| 16
4 files changed, 28 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/98cf6343/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f5a5f6a..588f58f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix NPE in SelectStatement with empty IN values (CASSANDRA-8419)
* Refactor SelectStatement, return IN results in natural order instead
of IN value list order (CASSANDRA-7981)
* Support UDTs, tuples, and collections in user-defined
http://git-wip-us.apache.org/repos/asf/cassandra/blob/98cf6343/src/java/org/apache/cassandra/cql3/restrictions/SingleColumnPrimaryKeyRestrictions.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/restrictions/SingleColumnPrimaryKeyRestrictions.java
b/src/java/org/apache/cassandra/cql3/restrictions/SingleColumnPrimaryKeyRestrictions.java
index 3858cdc..5c8386e 100644
---
a/src/java/org/apache/cassandra/cql3/restrictions/SingleColumnPrimaryKeyRestrictions.java
+++
b/src/java/org/apache/cassandra/cql3/restrictions/SingleColumnPrimaryKeyRestrictions.java
@@ -186,7 +186,7 @@ final class SingleColumnPrimaryKeyRestrictions extends
AbstractPrimaryKeyRestric
List values = r.values(options);
if (values.isEmpty())
-return null;
+return Collections.emptyList();
builder.addEachElementToAll(values);
checkFalse(builder.containsNull(), "Invalid null value for column
%s", def.name);
@@ -236,7 +236,12 @@ final class SingleColumnPrimaryKeyRestrictions extends
AbstractPrimaryKeyRestric
return compositeBuilder.buildWithEOC(eoc);
}
-compositeBuilder.addEachElementToAll(r.values(options));
+List values = r.values(options);
+
+if (values.isEmpty())
+return Collections.emptyList();
+
+compositeBuilder.addEachElementToAll(values);
checkFalse(compositeBuilder.containsNull(), "Invalid null
clustering key part %s", def.name);
keyPosition++;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/98cf6343/test/unit/org/apache/cassandra/cql3/MultiColumnRelationTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/MultiColumnRelationTest.java
b/test/unit/org/apache/cassandra/cql3/MultiColumnRelationTest.java
index 291afd8..b178498 100644
--- a/test/unit/org/apache/cassandra/cql3/MultiColumnRelationTest.java
+++ b/test/unit/org/apache/cassandra/cql3/MultiColumnRelationTest.java
@@ -441,11 +441,15 @@ public class MultiColumnRelationTest extends CQLTester
row(0, 0, 1, 1)
);
+assertEmpty(execute("SELECT * FROM %s WHERE a = ? and (b) IN ()",
0));
+
assertRows(execute("SELECT * FROM %s WHERE a = ? AND (b, c) IN
((?, ?)) ORDER BY b DESC, c DESC, d DESC", 0, 0, 1),
row(0, 0, 1, 1),
row(0, 0, 1, 0)
);
+assertEmpty(execute("SELECT * FROM %s WHERE a = ? AND (b, c) IN ()
ORDER BY b DESC, c DESC, d DESC", 0));
+
// IN on both partition key and clustering key
execute("INSERT INTO %s (a, b, c, d) VALUES (?, ?, ?, ?)", 1, 0,
0, 0);
execute("INSERT INTO %s (a, b, c, d) VALUES (?, ?, ?, ?)", 1, 0,
1, 0);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/98cf6343/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
b/test/unit/org/apache/cassandra/cql3/SingleColumnRelationTest.java
index 112da06..e6412a3 100644
--- a/te
[jira] [Created] (CASSANDRA-8433) Add jmx control to reset lifetime metrics to zero
Donald Smith created CASSANDRA-8433: --- Summary: Add jmx control to reset lifetime metrics to zero Key: CASSANDRA-8433 URL: https://issues.apache.org/jira/browse/CASSANDRA-8433 Project: Cassandra Issue Type: Improvement Reporter: Donald Smith Priority: Minor Often I change some parameter in cassandra, in the OS, or in an external component and want to see the effect on cassandra performance. Because some the jmx metrics are for the lifetime of the process, it's hard to see the effect of changes. It's inconvenient to restart all the nodes. And if you restart only some nodes (as I often do) then only those metrics reset to zero. The jmx interface should provide a way to reset all lifetime metrics to zero. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Uncomment CollectionsTest unit test cases
Repository: cassandra
Updated Branches:
refs/heads/trunk a7208383f -> 58c88b7d5
Uncomment CollectionsTest unit test cases
Patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-8426
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/58c88b7d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/58c88b7d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/58c88b7d
Branch: refs/heads/trunk
Commit: 58c88b7d54ca2290cee9cfb322d8b34e873a370c
Parents: a720838
Author: blerer
Authored: Fri Dec 5 12:19:00 2014 -0600
Committer: Tyler Hobbs
Committed: Fri Dec 5 12:19:00 2014 -0600
--
.../apache/cassandra/cql3/CollectionsTest.java | 234 +--
1 file changed, 117 insertions(+), 117 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/58c88b7d/test/unit/org/apache/cassandra/cql3/CollectionsTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/CollectionsTest.java
b/test/unit/org/apache/cassandra/cql3/CollectionsTest.java
index 2380c38..3d41ad6 100644
--- a/test/unit/org/apache/cassandra/cql3/CollectionsTest.java
+++ b/test/unit/org/apache/cassandra/cql3/CollectionsTest.java
@@ -21,29 +21,29 @@ import org.junit.Test;
public class CollectionsTest extends CQLTester
{
-//@Test
-//public void testMapBulkRemoval() throws Throwable
-//{
-//createTable("CREATE TABLE %s (k int PRIMARY KEY, m map)");
+@Test
+public void testMapBulkRemoval() throws Throwable
+{
+createTable("CREATE TABLE %s (k int PRIMARY KEY, m map)");
-//execute("INSERT INTO %s(k, m) VALUES (?, ?)", 0, map("k1", "v1",
"k2", "v2", "k3", "v3"));
+execute("INSERT INTO %s(k, m) VALUES (?, ?)", 0, map("k1", "v1", "k2",
"v2", "k3", "v3"));
-//assertRows(execute("SELECT * FROM %s"),
-//row(0, map("k1", "v1", "k2", "v2", "k3", "v3"))
-//);
+assertRows(execute("SELECT * FROM %s"),
+row(0, map("k1", "v1", "k2", "v2", "k3", "v3"))
+);
-//execute("UPDATE %s SET m = m - ? WHERE k = ?", set("k2"), 0);
+execute("UPDATE %s SET m = m - ? WHERE k = ?", set("k2"), 0);
-//assertRows(execute("SELECT * FROM %s"),
-//row(0, map("k1", "v1", "k3", "v3"))
-//);
+assertRows(execute("SELECT * FROM %s"),
+row(0, map("k1", "v1", "k3", "v3"))
+);
-//execute("UPDATE %s SET m = m + ?, m = m - ? WHERE k = ?", map("k4",
"v4"), set("k3"), 0);
+execute("UPDATE %s SET m = m + ?, m = m - ? WHERE k = ?", map("k4",
"v4"), set("k3"), 0);
-//assertRows(execute("SELECT * FROM %s"),
-//row(0, map("k1", "v1", "k4", "v4"))
-//);
-//}
+assertRows(execute("SELECT * FROM %s"),
+row(0, map("k1", "v1", "k4", "v4"))
+);
+}
@Test
public void testInvalidCollectionsMix() throws Throwable
@@ -71,146 +71,146 @@ public class CollectionsTest extends CQLTester
assertInvalid("UPDATE %s SET m = m - ? WHERE k = 0", map("a", "b",
"c", "d"));
}
-//@Test
-//public void testSets() throws Throwable
-//{
-//createTable("CREATE TABLE %s (k int PRIMARY KEY, s set)");
+@Test
+public void testSets() throws Throwable
+{
+createTable("CREATE TABLE %s (k int PRIMARY KEY, s set)");
-//execute("INSERT INTO %s(k, s) VALUES (0, ?)", set("v1", "v2", "v3",
"v4"));
+execute("INSERT INTO %s(k, s) VALUES (0, ?)", set("v1", "v2", "v3",
"v4"));
-//assertRows(execute("SELECT s FROM %s WHERE k = 0"),
-//row(set("v1", "v2", "v3", "v4"))
-//);
+assertRows(execute("SELECT s FROM %s WHERE k = 0"),
+row(set("v1", "v2", "v3", "v4"))
+);
-//execute("DELETE s[?] FROM %s WHERE k = 0", "v1");
+execute("DELETE s[?] FROM %s WHERE k = 0", "v1");
-//assertRows(execute("SELECT s FROM %s WHERE k = 0"),
-//row(set("v2", "v3", "v4"))
-//);
+assertRows(execute("SELECT s FROM %s WHERE k = 0"),
+row(set("v2", "v3", "v4"))
+);
-//// Full overwrite
-//execute("UPDATE %s SET s = ? WHERE k = 0", set("v6", "v5"));
+// Full overwrite
+execute("UPDATE %s SET s = ? WHERE k = 0", set("v6", "v5"));
-//assertRows(execute("SELECT s FROM %s WHERE k = 0"),
-//row(set("v5", "v6"))
-//);
+assertRows(execute("SELECT s FROM %s WHERE k = 0"),
+row(set("v5", "v6"))
+);
-//execute("UPDATE %s SET s = s + ? WHERE k = 0", set("v7"));
+execute("UPDATE %s SET s = s + ? WHERE k = 0", set("v7"));
-//assertRows(execute("SELECT s FROM
[jira] [Updated] (CASSANDRA-8426) CollectionsTest has some commented tests
[
https://issues.apache.org/jira/browse/CASSANDRA-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-8426:
---
Reviewer: Tyler Hobbs (was: Sylvain Lebresne)
> CollectionsTest has some commented tests
>
>
> Key: CASSANDRA-8426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8426
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Trivial
> Fix For: 3.0
>
> Attachments: CASSANDRA-8426.txt
>
>
> It seems that several test in {{CollectionsTest}} have been commented by
> mistake.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8432) Standalone Scrubber broken for LCS
Carl Yeksigian created CASSANDRA-8432: - Summary: Standalone Scrubber broken for LCS Key: CASSANDRA-8432 URL: https://issues.apache.org/jira/browse/CASSANDRA-8432 Project: Cassandra Issue Type: Bug Reporter: Carl Yeksigian Assignee: Marcus Eriksson Priority: Minor Fix For: 2.1.3 After CASSANDRA-8004, the compaction strategy for a column family will not be instanceof LeveledCompactionStrategy (StandaloneScrubber.java:100), so we don't check the manifest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8431) Stress should validate the results of queries in "user" profile mode
Benedict created CASSANDRA-8431: --- Summary: Stress should validate the results of queries in "user" profile mode Key: CASSANDRA-8431 URL: https://issues.apache.org/jira/browse/CASSANDRA-8431 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Benedict CASSANDRA-8429 was exhibited by the validation logic in stress. However at the moment the new-fangled profile driven "user" mode doesn't perform any validation. So as we default more and more to the new approach we will be less and less likely to spot correctness issues. Introducing validation logic here could be tricky, since we can support arbitrary user queries. However we could support a query mode where only the columns and number of cql rows to fetch are defined, for which we could calculate the exact result set we expect. There would be complications with insertions that proceed out-of-order, but we could either not support this mode, or have a validation mode that just ensures a superset of the data we know to be inserted has been. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Boudreault updated CASSANDRA-8430:
---
Labels: cassandra ttl (was: )
> Updating a row that has a TTL produce unexpected results
>
>
> Key: CASSANDRA-8430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Labels: cassandra, ttl
> Fix For: 2.0.11, 2.1.2, 3.0
>
> Attachments: test.sh
>
>
> Reported on stackoverflow:
> http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small
> script to reproduce the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
> pk | bar | foo
> +--+-
> 1 | test | 1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
> pk | bar| foo
> ++--
> 1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug
> or the expected behavior?
> (0 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
Alan Boudreault created CASSANDRA-8430:
--
Summary: Updating a row that has a TTL produce unexpected results
Key: CASSANDRA-8430
URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
Project: Cassandra
Issue Type: Bug
Reporter: Alan Boudreault
Fix For: 3.0, 2.1.2, 2.0.11
Attachments: test.sh
Reported on stackoverflow:
http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small script
to reproduce the issue with CCM, and here is it's output:
{code}
aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh
Current cluster is now: local
Insert data with a 5 sec TTL
INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
pk | bar | foo
+--+-
1 | test | 1
(1 rows)
Update data with no TTL
UPDATE ks.tbl set bar='change' where pk=1;
sleep 6 sec
BUG: Row should be deleted now, but isn't. and foo column has been deleted???
pk | bar| foo
++--
1 | change | null
(1 rows)
Insert data with a 5 sec TTL
INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
pk | bar | foo
+--+-
1 | test | 1
(1 rows)
Update data with a higher (10) TTL
UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
sleep 6 sec
BUG: foo column has been deleted?
pk | bar| foo
++--
1 | change | null
(1 rows)
sleep 5 sec
Data is deleted now after the second TTL set during the update. Is this a bug
or the expected behavior?
(0 rows)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8429) Stress on trunk fails mixed workload on missing keys
Ariel Weisberg created CASSANDRA-8429: - Summary: Stress on trunk fails mixed workload on missing keys Key: CASSANDRA-8429 URL: https://issues.apache.org/jira/browse/CASSANDRA-8429 Project: Cassandra Issue Type: Bug Environment: Ubuntu 14.04 Reporter: Ariel Weisberg Assignee: Ariel Weisberg Starts as part of merge commit 25be46497a8df46f05ffa102bc645bfd684ea48a Stress will say that a key wasn't validated because it isn't returned even though it's loaded. The key will eventually appear and can be queried using cqlsh. Reproduce with #!/bin/sh rm /tmp/fark ROWCOUNT=1000 SCHEMA='-col n=fixed(1) -schema compaction(strategy=LeveledCompactionStrategy) compression=LZ4Compressor' ./cassandra-stress write n=$ROWCOUNT -node xh61 -pop seq=1..$ROWCOUNT no-wrap -rate threads=25 $SCHEMA ./cassandra-stress mixed "ratio(read=2)" n=1 -node xh61 -pop "dist=extreme(1..$ROWCOUNT,0.6)" -rate threads=25 $SCHEMA -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8428) Nodetool Drain kills C* Process
[
https://issues.apache.org/jira/browse/CASSANDRA-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235686#comment-14235686
]
Philip Thompson commented on CASSANDRA-8428:
Anyway, this is affecting one of the upgrade_supercolumns_test dtests,
upgrade_with_counters, because we're trying to drain before shutdown.
> Nodetool Drain kills C* Process
> ---
>
> Key: CASSANDRA-8428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8428
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Brandon Williams
> Labels: nodetool
> Fix For: 2.0.12
>
> Attachments: system.log
>
>
> Nodetool Drain is documented at http://wiki.apache.org/cassandra/NodeTool and
> in the nodetool help to flush a node and stop accepting writes. This is the
> behavior I see with 2.1.2.
> In 2.0.11 and 1.2.19, instead the Cassandra Process is killed. In the 1.2.19
> logs, I see:
> {code}
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,234
> StorageService.java (line 964)
> DRAINING: starting drain process
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,235
> ThriftServer.java (line 116) S
> top listening to thrift clients
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,239 Server.java
> (line 159) Stop li
> stening for CQL clients
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,239
> Gossiper.java (line 1203) Announcing shutdown
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:46,240
> MessagingService.java (line 696) Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.1] 2014-12-05 10:32:46,241 MessagingService.java (line
> 919) MessagingService shutting down server thread.{code}
> So it appears this in an intentional shut down, in which case the docs and
> help are wrong. I could not find a JIRA that described the change in behavior
> moving to 2.1.
> Other users on IRC report that drain works as expected for them on 1.2.19.
> Attached are 2.0 logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8428) Nodetool Drain kills C* Process
[
https://issues.apache.org/jira/browse/CASSANDRA-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235683#comment-14235683
]
Philip Thompson commented on CASSANDRA-8428:
{code}
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:54,0
11 StorageService.java:1025 - DRAINING: starting drain process
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:54,0
12 ThriftServer.java:142 - Stop listening to thrift clients
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:54,0
18 Server.java:213 - Stop listening for CQL clients
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:54,0
19 Gossiper.java:1318 - Announcing shutdown
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:56,0
20 MessagingService.java:705 - Waiting for messaging service to
quiesce
INFO [ACCEPT-localhost/127.0.0.1] 2014-12-05 11:16:56,021 Mess
agingService.java:953 - MessagingService has terminated the acc
ept() thread
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:56,0
22 ColumnFamilyStore.java:840 - Enqueuing flush of peers: 152 (
0%) on-heap, 0 (0%) off-heap
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:56,0
23 ColumnFamilyStore.java:840 - Enqueuing flush of compaction_h
istory: 1187 (0%) on-heap, 0 (0%) off-heap
INFO [MemtableFlushWriter:2] 2014-12-05 11:16:56,023 Memtable.
java:325 - Writing Memtable-peers@848262695(0 serialized bytes,
1 ops, 0%/0% of on/off-heap limit)
INFO [MemtableFlushWriter:1] 2014-12-05 11:16:56,024 Memtable.
java:325 - Writing Memtable-compaction_history@1754666079(229 s
erialized bytes, 9 ops, 0%/0% of on/off-heap limit)
INFO [MemtableFlushWriter:2] 2014-12-05 11:16:56,030 Memtable.
java:364 - Completed flushing /Users/philipthompson/cstar/cassa
ndra/bin/../data/data/system/peers-37f71aca7dc2383ba70672528af04d4f/system-peers-ka-1-Data.db
(30 bytes) for commitlog position ReplayPosition(segmentId=1417796200082,
position=108607)
INFO [MemtableFlushWriter:1] 2014-12-05 11:16:56,031 Memtable.java:364 -
Completed flushing
/Users/philipthompson/cstar/cassandra/bin/../data/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/system-compaction_history-ka-1-Data.db
(239 bytes) for commitlog position ReplayPosition(segmentId=1417796200082,
position=108607)
ERROR [COMMIT-LOG-ALLOCATOR] 2014-12-05 11:16:56,087 StorageService.java:383 -
Stopping gossiper
WARN [COMMIT-LOG-ALLOCATOR] 2014-12-05 11:16:56,087 StorageService.java:291 -
Stopping gossip by operator request
INFO [COMMIT-LOG-ALLOCATOR] 2014-12-05 11:16:56,088 Gossiper.java:1318 -
Announcing shutdown
ERROR [COMMIT-LOG-ALLOCATOR] 2014-12-05 11:16:58,096 CommitLog.java:367 -
Failed managing commit log segments. Commit disk failure policy is stop;
terminating thread
org.apache.cassandra.io.FSWriteError:
java.nio.channels.ClosedByInterruptException
at
org.apache.cassandra.db.commitlog.CommitLogSegment.(CommitLogSegment.java:177)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:365)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManager$3.call(CommitLogSegmentManager.java:369)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManager$3.call(CommitLogSegmentManager.java:366)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:153)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
Caused by: java.nio.channels.ClosedByInterruptException: null
at
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
~[na:1.7.0_67]
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:919)
~[na:1.7.0_67]
at
org.apache.cassandra.db.commitlog.CommitLogSegment.(CommitLogSegment.java:166)
~[main/:na]
... 6 common frames omitted
INFO [RMI TCP Connection(2)-10.150.0.64] 2014-12-05 11:16:58,096
StorageService.java:1025 - DRAINED
{code}
Is what I see in 2.1.2
> Nodetool Drain kills C* Process
> ---
>
> Key: CASSANDRA-8428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8428
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Brandon Williams
> Labels: nodetool
> Fix For: 2.0.12
>
> Attachments: system.log
>
>
> Nodetool Drain is documented at http://wiki.apache.org/cassandra/NodeTool and
> in the nodetool help to flush a node and stop accepting writes. This is the
> behavior I see with 2.1.2.
> In 2.0.11 and 1.2.19, instead the Cassandra Process is killed. In the 1.2.19
> logs, I see:
> {code}
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,234
[jira] [Commented] (CASSANDRA-8428) Nodetool Drain kills C* Process
[
https://issues.apache.org/jira/browse/CASSANDRA-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235681#comment-14235681
]
Philip Thompson commented on CASSANDRA-8428:
In 2.1.2, I see the same "Announcing shutdown" in the logs, but the process
remains up. With 2.1-HEAD, the process is killed.
> Nodetool Drain kills C* Process
> ---
>
> Key: CASSANDRA-8428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8428
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Brandon Williams
> Labels: nodetool
> Fix For: 2.0.12
>
> Attachments: system.log
>
>
> Nodetool Drain is documented at http://wiki.apache.org/cassandra/NodeTool and
> in the nodetool help to flush a node and stop accepting writes. This is the
> behavior I see with 2.1.2.
> In 2.0.11 and 1.2.19, instead the Cassandra Process is killed. In the 1.2.19
> logs, I see:
> {code}
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,234
> StorageService.java (line 964)
> DRAINING: starting drain process
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,235
> ThriftServer.java (line 116) S
> top listening to thrift clients
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,239 Server.java
> (line 159) Stop li
> stening for CQL clients
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,239
> Gossiper.java (line 1203) Announcing shutdown
> INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:46,240
> MessagingService.java (line 696) Waiting for messaging service to quiesce
> INFO [ACCEPT-/127.0.0.1] 2014-12-05 10:32:46,241 MessagingService.java (line
> 919) MessagingService shutting down server thread.{code}
> So it appears this in an intentional shut down, in which case the docs and
> help are wrong. I could not find a JIRA that described the change in behavior
> moving to 2.1.
> Other users on IRC report that drain works as expected for them on 1.2.19.
> Attached are 2.0 logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8428) Nodetool Drain kills C* Process
Philip Thompson created CASSANDRA-8428:
--
Summary: Nodetool Drain kills C* Process
Key: CASSANDRA-8428
URL: https://issues.apache.org/jira/browse/CASSANDRA-8428
Project: Cassandra
Issue Type: Bug
Reporter: Philip Thompson
Assignee: Brandon Williams
Fix For: 2.0.12
Attachments: system.log
Nodetool Drain is documented at http://wiki.apache.org/cassandra/NodeTool and
in the nodetool help to flush a node and stop accepting writes. This is the
behavior I see with 2.1.2.
In 2.0.11 and 1.2.19, instead the Cassandra Process is killed. In the 1.2.19
logs, I see:
{code}
INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,234
StorageService.java (line 964)
DRAINING: starting drain process
INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,235
ThriftServer.java (line 116) S
top listening to thrift clients
INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,239 Server.java
(line 159) Stop li
stening for CQL clients
INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:44,239 Gossiper.java
(line 1203) Announcing shutdown
INFO [RMI TCP Connection(2)-192.168.1.5] 2014-12-05 10:32:46,240
MessagingService.java (line 696) Waiting for messaging service to quiesce
INFO [ACCEPT-/127.0.0.1] 2014-12-05 10:32:46,241 MessagingService.java (line
919) MessagingService shutting down server thread.{code}
So it appears this in an intentional shut down, in which case the docs and help
are wrong. I could not find a JIRA that described the change in behavior moving
to 2.1.
Other users on IRC report that drain works as expected for them on 1.2.19.
Attached are 2.0 logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8424) Collection filtering not working when using PK
[
https://issues.apache.org/jira/browse/CASSANDRA-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235540#comment-14235540
]
Lex Lythius commented on CASSANDRA-8424:
Thanks for the explanation, Sylvain. I'll wait for 3.0 then.
Just so that this doesn't get overlooked when refactoring takes place, I added
the corresponding "#8099 blocks #8424" link.
Cheers!
> Collection filtering not working when using PK
> --
>
> Key: CASSANDRA-8424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8424
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL spec 3.2.0 | Native
> protocol v3]
> Ubuntu 14.04.5 64-bit
>Reporter: Lex Lythius
>Priority: Minor
> Labels: collections
>
> I can do queries for collection keys/values as detailed in
> http://www.datastax.com/dev/blog/cql-in-2-1 without problems. Even without
> having a secondary index on the collection it will work (with {{ALLOW
> FILTERING}}) but only as long as the query is performed through a *secondary*
> index. If you go through PK it won't. Of course full-scan filtering query is
> not allowed.
> As an example, I created this table:
> {code:SQL}
> CREATE TABLE test.uloc9 (
> usr int,
> type int,
> gb ascii,
> gb_q ascii,
> info map,
> lat float,
> lng float,
> q int,
> traits set,
> ts timestamp,
> PRIMARY KEY (usr, type)
> );
> CREATE INDEX uloc9_gb ON test.uloc9 (gb);
> CREATE INDEX uloc9_gb_q ON test.uloc9 (gb_q);
> CREATE INDEX uloc9_traits ON test.uloc9 (traits);
> {code}
> then added some data and queried:
> {code}
> cqlsh:test> select * from uloc9 where gb='/nw' and info contains 'argentina'
> allow filtering;
> usr | type | gb | gb_q | info | lat
> | lng | q | traits | ts
> -+--+-+---+--+--+--+---++--
>1 |0 | /nw | /nw:1 | {'ci': 'san antonio', 'co': 'argentina'} |
> -40.74000168 | -65.8305 | 1 | {'r:photographer'} | 2014-11-04
> 18:20:29-0300
>1 |1 | /nw | /nw:1 | {'ci': 'san antonio', 'co': 'argentina'} |
> -40.75799942 | -66.00800323 | 1 | {'r:photographer'} | 2014-11-04
> 18:20:29-0300
> (2 rows)
> cqlsh:test> select * from uloc9 where usr=1 and info contains 'argentina'
> allow filtering;
> code=2200 [Invalid query] message="No indexed columns present in by-columns
> clause with Equal operator"
> cqlsh:test> select * from uloc9 where usr=1 and type=0 and info contains
> 'argentina' allow filtering;
> code=2200 [Invalid query] message="No indexed columns present in by-columns
> clause with Equal operator"
> {code}
> Maybe I got things wrong, but I don't see any reasons why collection
> filtering should fail when using PK while it succeeds using any secondary
> index (related or otherwise).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-4987) Support more queries when ALLOW FILTERING is used.
[
https://issues.apache.org/jira/browse/CASSANDRA-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajanarayanan Thottuvaikkatumana reassigned CASSANDRA-4987:
---
Assignee: Rajanarayanan Thottuvaikkatumana
> Support more queries when ALLOW FILTERING is used.
> --
>
> Key: CASSANDRA-4987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4987
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Rajanarayanan Thottuvaikkatumana
> Labels: cql
> Fix For: 3.0
>
>
> Even after CASSANDRA-4915, there is still a bunch of queries that we don't
> support even if {{ALLOW FILTERING}} is used. Typically, pretty much any
> queries with restriction on a non-primary-key column unless we have one of
> those restriction that is an EQ on an indexed column.
> If {{ALLOW FILTERING}} is used, we could allow those queries out of
> convenience.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4987) Support more queries when ALLOW FILTERING is used.
[
https://issues.apache.org/jira/browse/CASSANDRA-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235375#comment-14235375
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-4987:
-
Apart from the above changes, for sure the following tests also have to be
changed for sure.
{code}
FrozenCollectionsTest.java
ContainsRelationTest.java
{code}
> Support more queries when ALLOW FILTERING is used.
> --
>
> Key: CASSANDRA-4987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4987
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
> Labels: cql
> Fix For: 3.0
>
>
> Even after CASSANDRA-4915, there is still a bunch of queries that we don't
> support even if {{ALLOW FILTERING}} is used. Typically, pretty much any
> queries with restriction on a non-primary-key column unless we have one of
> those restriction that is an EQ on an indexed column.
> If {{ALLOW FILTERING}} is used, we could allow those queries out of
> convenience.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4987) Support more queries when ALLOW FILTERING is used.
[
https://issues.apache.org/jira/browse/CASSANDRA-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235370#comment-14235370
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-4987:
-
[~slebresne], I had a look at the code and the here is one place where a change
can be made. In the org/apache/cassandra/cql3/statements/SelectStatement.java
file, this conditional check to be introduced
{code}
if(!parameters.allowFiltering)
{
secondaryIndexManager.validateIndexSearchersForQuery(expressions);
}
{code}
In the org/apache/cassandra/db/index/SecondaryIndexManager.java file, change
the exception message to give hint about the ALLOW FILTERING CLAUSE
{code}
StringBuilder sb = new StringBuilder("No secondary indexes on the restricted
columns support the provided operators. If you want to execute this query
despite the performance unpredictability, use ALLOW FILTERING: ");
{code}
If we make the above changes, the behaviour will be something like given below.
{code}
cqlsh> use test;
cqlsh:test> select * from Videos;
videoid | videoname | description | tags | upload_date | username
-+---+-+--+-+--
(0 rows)
cqlsh:test> select * from videos where tags = 'Cass';
code=2200 [Invalid query] message="No secondary indexes on the restricted
columns support the provided operators. If you want to execute this query
despite the performance unpredictability, use ALLOW FILTERING: "
cqlsh:test> select * from videos where tags = 'Cass' ALLOW FILTERING;
videoid | videoname | description | tags | upload_date | username
-+---+-+--+-+--
(0 rows)
cqlsh:test>
{code}
I will have a look at other places where there is a change required. Please let
me know if this is right and a patch needs to be generated. Thanks
> Support more queries when ALLOW FILTERING is used.
> --
>
> Key: CASSANDRA-4987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4987
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
> Labels: cql
> Fix For: 3.0
>
>
> Even after CASSANDRA-4915, there is still a bunch of queries that we don't
> support even if {{ALLOW FILTERING}} is used. Typically, pretty much any
> queries with restriction on a non-primary-key column unless we have one of
> those restriction that is an EQ on an indexed column.
> If {{ALLOW FILTERING}} is used, we could allow those queries out of
> convenience.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8427) An error is written to System.out when UserTypesTest is run
Benjamin Lerer created CASSANDRA-8427:
-
Summary: An error is written to System.out when UserTypesTest is
run
Key: CASSANDRA-8427
URL: https://issues.apache.org/jira/browse/CASSANDRA-8427
Project: Cassandra
Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
Priority: Minor
When running {{org.apache.cassandra.cql3.UserTypesTest}} the following error is
printed out to the console.
{code}ERROR 09:58:41 Fatal exception in thread Thread[OptionalTasks:1,5,main]
java.lang.RuntimeException: java.lang.RuntimeException: Error setting schema
for test (query was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:188)
~[classes/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
~[na:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
Caused by: java.lang.RuntimeException: Error setting schema for test (query
was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:413)
~[classes/:na]
at org.apache.cassandra.cql3.CQLTester.access$3(CQLTester.java:404)
~[classes/:na]
at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:167)
~[classes/:na]
... 7 common frames omitted
Caused by: java.lang.RuntimeException: Error validating query DROP TYPE IF
EXISTS cql_test_keyspace.type_2
at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:374)
~[main/:na]
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:409)
~[classes/:na]
... 9 common frames omitted
Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Cannot drop
user type cql_test_keyspace.type_2 as it is still used by user type type_3
at
org.apache.cassandra.cql3.statements.DropTypeStatement.validate(DropTypeStatement.java:93)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:361)
~[main/:na]
... 10 common frames omitted
ERROR 09:58:41 Fatal exception in thread Thread[OptionalTasks:1,5,main]
java.lang.RuntimeException: java.lang.RuntimeException: Error setting schema
for test (query was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:188)
~[classes/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
~[na:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
Caused by: java.lang.RuntimeException: Error setting schema for test (query
was: DROP TYPE IF EXISTS cql_test_keyspace.type_2)
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:413)
~[classes/:na]
at org.apache.cassandra.cql3.CQLTester.access$3(CQLTester.java:404)
~[classes/:na]
at org.apache.cassandra.cql3.CQLTester$1.run(CQLTester.java:167)
~[classes/:na]
... 7 common frames omitted
Caused by: java.lang.RuntimeException: Error validating query DROP TYPE IF
EXISTS cql_test_keyspace.type_2
at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:374)
~[main/:na]
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:409)
~[classes/:na]
... 9 common frames omitted
Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Cannot drop
user type cql_test_keyspace.type_2 as it is still used by user type type_3
at
org.apache.cassandra.cql3.statements.DropTypeStatement.validate(DropTypeStatement.java:93)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeOnc
[jira] [Updated] (CASSANDRA-8426) CollectionsTest has some commented tests
[
https://issues.apache.org/jira/browse/CASSANDRA-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-8426:
--
Attachment: CASSANDRA-8426.txt
The patch removes the {{//}}.
> CollectionsTest has some commented tests
>
>
> Key: CASSANDRA-8426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8426
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Trivial
> Fix For: 3.0
>
> Attachments: CASSANDRA-8426.txt
>
>
> It seems that several test in {{CollectionsTest}} have been commented by
> mistake.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8426) CollectionsTest has some commented tests
[
https://issues.apache.org/jira/browse/CASSANDRA-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-8426:
-
Assignee: Benjamin Lerer
> CollectionsTest has some commented tests
>
>
> Key: CASSANDRA-8426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8426
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Trivial
> Fix For: 3.0
>
>
> It seems that several test in {{CollectionsTest}} have been commented by
> mistake.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8426) CollectionsTest has some commented tests
Benjamin Lerer created CASSANDRA-8426:
-
Summary: CollectionsTest has some commented tests
Key: CASSANDRA-8426
URL: https://issues.apache.org/jira/browse/CASSANDRA-8426
Project: Cassandra
Issue Type: Bug
Reporter: Benjamin Lerer
Priority: Trivial
Fix For: 3.0
It seems that several test in {{CollectionsTest}} have been commented by
mistake.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-7026) CQL:WHERE ... IN with full partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-7026: - Assignee: Benjamin Lerer > CQL:WHERE ... IN with full partition keys > - > > Key: CASSANDRA-7026 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7026 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: Dan Hunt >Assignee: Benjamin Lerer >Priority: Minor > Labels: cql > > It would be handy to be able to pass in a list of fully qualified composite > partition keys in an IN filter to retrieve multiple distinct rows with a > single select. Not entirely sure how that would work. It looks like maybe > it could be done with the existing token() function, like: > SELECT * FROM table WHERE token(keyPartA, keyPartB) IN (token(1, 1), token(4, > 2)) > Though, I guess you'd also want some way to pass a list of tokens to a > prepared statement through the driver. This of course all assumes that an IN > filter could be faster than a bunch of prepared statements, which might not > be true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-6706) Duplicate rows returned when in clause has repeated values
[
https://issues.apache.org/jira/browse/CASSANDRA-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-6706:
-
Assignee: Benjamin Lerer
> Duplicate rows returned when in clause has repeated values
> --
>
> Key: CASSANDRA-6706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6706
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Found on
> [cqlsh 4.1.0 | Cassandra 2.0.3-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
> 19.38.0]
>Reporter: Gavin Casey
>Assignee: Benjamin Lerer
> Labels: cql
> Fix For: 3.0
>
>
> If a value is repeated within an IN clause then repeated rows are returned
> for the repeats:
> cqlsh> create table t1(c1 text primary key);
> cqlsh> insert into t1(c1) values ('A');
> cqlsh> select * from t1;
> c1
>
> A
> cqlsh> select * from t1 where c1 = 'A';
> c1
>
> A
> cqlsh> select * from t1 where c1 in( 'A');
> c1
>
> A
> cqlsh:dslog> select * from t1 where c1 in( 'A','A');
> c1
>
> A
> A
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8393) support quoted identifiers for index names
[ https://issues.apache.org/jira/browse/CASSANDRA-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-8393: - Assignee: Benjamin Lerer > support quoted identifiers for index names > -- > > Key: CASSANDRA-8393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8393 > Project: Cassandra > Issue Type: Bug > Environment: v2.1.2 >Reporter: Jonathan Halliday >Assignee: Benjamin Lerer > Fix For: 2.1.3 > > > CREATE TABLE "quoted_ident" ... > is valid in cql, whilst > CREATE INDEX "quoted_ident" ... > is not. > This is inconsistent and troublesome for frameworks or tooling that needs to > sling around case sensitive identifiers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8215) Empty IN Clause still returns data
[
https://issues.apache.org/jira/browse/CASSANDRA-8215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer resolved CASSANDRA-8215.
---
Resolution: Duplicate
The patch for #8419 also solve this problem.
> Empty IN Clause still returns data
> --
>
> Key: CASSANDRA-8215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8215
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benjamin Lerer
> Fix For: 3.0
>
>
> The dtest cql_tests.py:TestCQL.empty_in_test is failing on trunk HEAD but not
> on 2.1-HEAD.
> The test uses the following table: {code} CREATE TABLE test (k1 int, k2 int,
> v int, PRIMARY KEY (k1, k2)) {code} then performs a number of inserts.
> The test then asserts that {code} SELECT v FROM test WHERE k1 = 0 AND k2 IN
> () {code} returns no data, however it is returning everywhere k1 = 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8419) NPE in SelectStatement
[
https://issues.apache.org/jira/browse/CASSANDRA-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-8419:
--
Attachment: CASSANDRA-8419.txt
> NPE in SelectStatement
> --
>
> Key: CASSANDRA-8419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8419
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Benjamin Lerer
> Fix For: 3.0
>
> Attachments: CASSANDRA-8419.txt
>
>
> The dtest {{cql_tests.py:TestCQL.empty_in_test}} is failing in trunk with a
> Null Pointer Exception. The stack trace is:
> {code}ERROR [SharedPool-Worker-1] 2014-12-03 16:24:16,274
> ErrorMessage.java:243 - Unexpected exception
> during request
> java.lang.NullPointerException: null
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:213)
> ~[guava-16.0
> .jar:na]
> at
> com.google.common.collect.Lists$TransformingSequentialList.(Lists.java:525)
> ~[gu
> ava-16.0.jar:na]
> at com.google.common.collect.Lists.transform(Lists.java:508)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.composites.Composites.toByteBuffers(Composites.java:45)
> ~[main
> /:na]
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnPrimaryKeyRestrictions.values(Singl
> eColumnPrimaryKeyRestrictions.java:257) ~[main/:na]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getPartitionKeys(StatementRestrictions.java:362)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:296)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getPageableCommand(SelectStatement.java:205)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:165)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:72)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:239)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:261)
> ~[main/:na]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:118)
> ~[main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
> [main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
> [main/:na]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]{code}
> The error occurred while executing {{SELECT v FROM test_compact WHERE k1 IN
> ()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
